Saber se um numero ja existe num arreio

Em Perl, numa linha:
Código:
[me@mybox] ~: perl -le '@a=qw/el1 el2 el3 el4 el5/;$n="el7";push @a,$n if grep {$n ne $_} @a;print "@a"'
el1 el2 el3 el4 el5 el7
 
Código:
; 1º arg = endereço do array
; 2º arg = tamanho do array
; 3º arg = numero a procurar (Dword)
exite_no_array:
    push ebp
    mov ebp, esp
    push ecx
    push ebx
    mov eax, [ebp+16]
    mov ecx, [ebp+12]
ciclo:    
    mov ebx, [eax]
    cmp ebx, [ebp+8]
    je achou
    add eax, 4
    dec ecx
    cmp ecx, 0
    jl nao_achou
    jmp ciclo
nao_achou:
    xor eax, eax
    jmp fim
achou:    
    mov eax, 1
fim:    
    pop ebx
    pop ecx
    pop ebp
    ret
Só pa xatear, em assembler x86 :)
 
Última edição:
Já agora... e só porque sim :007: Aqui está a função em Assembly X86 GAS GNU:

#Parametros passados na pilha (por ordem): endereço do vector, tamanho do vector, num a procurar
#Devolve 0 ou 1 na pilha conforme o numero exista ou nao
EXISTENUM:
pushl %ebp
movl %esp, %ebp

movl 16(%ebp), %eax
movl $0, %ecx
movl $0, %ebx
CICLO:
cmpl (%eax, %ecx, 4), 8(%ebp)
je EXISTE
incl %ecx
cmpl 12(%ebp), %ecx
je FIM
jmp CICLO
EXISTE:
movl $1, %ebx
FIM:
movl %ebx, 16(%ebp)
popl %ebp
ret $8​
EDIT: DAMN alguem teve a mesma ideia que eu! Escrevemos o programa ao mesmo tempo ahah :P
Anyway, acho que o meu ta mais pequeno :P E tens aí umas coisas mal com os ESP e EBP e também nao limpas a pilha no fim
 
Última edição:
já agora em C#


Código:
public static bool existNumInArray(int[]a,int n){
			foreach(int pos in a)
				if(pos==n)return true;
			return false;
		}
 
Já agora... e só porque sim :007: Aqui está a função em Assembly X86 GAS GNU:



EDIT: DAMN alguem teve a mesma ideia que eu! Escrevemos o programa ao mesmo tempo ahah :P
Anyway, acho que o meu ta mais pequeno :P E tens aí umas coisas mal com os ESP e EBP.

:) ficam as duas versões do asm...
eu tnh mais push's k tu! ;) anyway, desde que funcionem....
 
Corrijam-me se estiver errado, não se deviam evitar breaks? Qualquer coisa por causa de terminação brusca da execução ou coisa e tal. Pelo menos ensinaram-me assim lol. Só os uso em switch, porque aliás é o único modo permitidos pelos profs :P

cumpzz
 
Corrijam-me se estiver errado, não se deviam evitar breaks? Qualquer coisa por causa de terminação brusca da execução ou coisa e tal. Pelo menos ensinaram-me assim lol. Só os uso em switch, porque aliás é o único modo permitidos pelos profs :P

cumpzz

Eu penso que um break, ou um return é mais leve que percorrer uma colecção até ao fim tendo já encontrado o que andamos à procura.. :P
 
Eu penso que um break, ou um return é mais leve que percorrer uma colecção até ao fim tendo já encontrado o que andamos à procura.. :P

Não necessariamente...
Também me ensinaram que breaks são algo a evitar... deve-se sim pôr mais uma condição na guarda do ciclo para que pare de percorrer quando algo acontece.
Tal como o MadOnion fez no código dele (os profs dele foram os mesmos q os meus portanto ele tb deve ter aprendido isso :lol: :P )
 
Última edição:
expliquem lá melhor o porquê de o break ser uma instrução a evitar? é que tecnicamente, e como podem ver pelas versões assembly que foram apresentadas, não passa de um JE outoftheloop

a mim parece-me que essas recomendações são apenas por causa da compreensibilidade do código (ou seja, resquícios do Dijkstra e do seu GOTO visto que os breaks/continues são GOTO controlados)
 
expliquem lá melhor o porquê de o break ser uma instrução a evitar? é que tecnicamente, e como podem ver pelas versões assembly que foram apresentadas, não passa de um JE outoftheloop

a mim parece-me que essas recomendações são apenas por causa da compreensibilidade do código (ou seja, resquícios do Dijkstra e do seu GOTO visto que os breaks/continues são GOTO controlados)


Concordo plenamente, uma nova condição vai efectuar mais comparações e segundo o que eu aprendi as comparações também são pesadas.
 
Concordo plenamente, uma nova condição vai efectuar mais comparações e segundo o que eu aprendi as comparações também são pesadas.

é mesmo!
e a instrução k deve ser evitada é o GOTO, não o break...
só pa terem uma ideia:
Código:
r3pek@trinity /usr/src/linux $ grep -Ri break * | wc -l
70581


o kernel linux só tem 70581 breaks no código...... só. e não me parece k esteja mal feito...
 
o kernel linux só tem 70581 breaks no código...... só. e não me parece k esteja mal feito...
err..... that's not true ;-)

esse grep está a ler ficheiros txt :-P

Algo mais aproximado:
Código:
[me@mybox] /usr/src/linux: ack -c "break;" | wc -l
23645
... e mesmo assim, pode estar a contar 'break;' dentro de comentários.
 
err..... that's not true ;-)

esse grep está a ler ficheiros txt :-P

Algo mais aproximado:
Código:
[me@mybox] /usr/src/linux: ack -c "break;" | wc -l
23645
... e mesmo assim, pode estar a contar 'break;' dentro de comentários.
buah :P tá bem.... :) o k nao invalida k eles estão la e k são bastante usados ;)
 
a mim tb me disseram para evitar break's e goto's, nada que um simples while ou um do não faça. em termos de peso acho que um while tem o mesmo peso que um for com break.
 
Pessoal, já se aqui falou da questão da pesquisa em arrays, ser preciso percorrer o array todo, etc. Para resolvermos todos estes problemas, a minha sugestão seria implementar-se a pesquisa dicotómica em array. Este algoritmo é muito simples de perceber e implementar e é de uma eficácia espectacular.

A minha experiência neste algoritmo é única e exclusivamente em C++, mas claro que em todas as linguagens é possível implementar.

Vá, cumps.

P.S.: não coloco aqui o código da pesquisa dicotómica em arrays pois acho que assim se estaria a perder o desafio todo, e em programação o prazer pelo desafio é fundamental. Googlem para descobrirem mais coisas.
 
Pessoal, já se aqui falou da questão da pesquisa em arrays, ser preciso percorrer o array todo, etc. Para resolvermos todos estes problemas, a minha sugestão seria implementar-se a pesquisa dicotómica em array. Este algoritmo é muito simples de perceber e implementar e é de uma eficácia espectacular.

A minha experiência neste algoritmo é única e exclusivamente em C++, mas claro que em todas as linguagens é possível implementar.

Vá, cumps.

P.S.: não coloco aqui o código da pesquisa dicotómica em arrays pois acho que assim se estaria a perder o desafio todo, e em programação o prazer pelo desafio é fundamental. Googlem para descobrirem mais coisas.
mas para isso tens k partir do presuposto que o array está ordenado..... o k nos levaria agora ks a fazer uma classe só para trabalhar com o array :) pk tinha k se fazer o insert, a pesquisa, a remoção.... portanto, uma classe :)
 
mas para isso tens k partir do presuposto que o array está ordenado..... o k nos levaria agora ks a fazer uma classe só para trabalhar com o array :) pk tinha k se fazer o insert, a pesquisa, a remoção.... portanto, uma classe :)

E digo-te que não ficaria mal haver uma classe que virtualizasse o array e todas as suas características e operações. Aliás, se o C++ existe para além do C é mesmo por causa das classes.

Pensando em outras linguagens, como JAVA e C#, as classes são obrigatoriamente definidas, fazem parte do código que é necessário escrever para que um programa funcione.

Por isso, não me parece que a implementação de uma classe para controlar o array fosse uma coisa negativa. Muito pelo contrário.

Já agora, para ordenar o array, duas opções: bubblesort ou quicksort (quem souber os dois algoritmos, deverá optar pelo último, pelo menos na minha opnião).

Vá, cumps
 
E digo-te que não ficaria mal haver uma classe que virtualizasse o array e todas as suas características e operações. Aliás, se o C++ existe para além do C é mesmo por causa das classes.

Pensando em outras linguagens, como JAVA e C#, as classes são obrigatoriamente definidas, fazem parte do código que é necessário escrever para que um programa funcione.

Por isso, não me parece que a implementação de uma classe para controlar o array fosse uma coisa negativa. Muito pelo contrário.

Já agora, para ordenar o array, duas opções: bubblesort ou quicksort (quem souber os dois algoritmos, deverá optar pelo último, pelo menos na minha opnião).

Vá, cumps

tb nao digo o contrario. é só para nao tar a desviar do assinto do topico. e sim, quicksort é o melhor.
 
Back
Topo