Monografias.com <http://br.monografias.

com/>

Adicionar a favoritos <javascript:favoritohome();> Convidar um

amigo <http://www1.monografias.com/cgi-bin2/recomendar.pl> en
Espa�ol <http://www.monografias.com/>

* Monograf�as </>
* Novos </New>
* Publique </participar.shtml>
* Ajuda </ayuda/ayuda.shtml>

*Descargar* <algoritmos-primero.zip> Imprimir

<javascript:window.print();> Adicionar a favoritos
<javascript:favorito();> Convidar um amigo
<http://www1.monografias.com/cgi-bin2/recomendar.pl>

/(Viene de la p�gina anterior)/

*P�gina anterior* <algoritmos-primero.shtml> *Voltar ao in�cio do

trabalho* <algoritmos-primero.shtml> *P�gina seguinte*
<algoritmos-primero.shtml>

2. Como representar um algoritmo?

Este artigo � o segundo da s�rie sobre *algoritmos*. Se voc� ainda n�o

leu, leia a parte 1: O que � um algoritmo?

No primeiro artigo, expliquei o que � um algoritmo e at� citei exemplos

do cotidiano, como *acordar* ou *falar com outra pessoa*. Talvez voc�
nem tenha se dado conta, mas usando /listas numeradas/ eu representei os
algoritmos ali presentes, inclusive destacando a *entrada* e a *sa�da**
*de cada situa��o-problema. Mas n�o � sempre assim que representamos
algoritmos.

N�o existe uma regra padr�o para a representa��o de algoritmos. Cada

pessoa escreve de forma diferente, mas o importante � ser leg�vel e
convencionado. Por exemplo, o livro *Algoritmos: Teoria e Pr�tica* traz
nas p�ginas 14 e 15 conven��es do pseudoc�digo que utiliza no livro
inteiro. J� eu, quando vou passar o mesmo algoritmo, utilizaria outro
tipo de c�digo, voc� pode utilizar outro, e por a� vai. Mas todos t�m
que ter o mesmo foco: legibilidade e f�cil implementa��o para qualquer
linguagem.

Os pseudoc�digos costumam parecer um c�digo em linguagem Pascal

traduzido para a sua l�ngua. Usam quase sempre estruturas que estamos
acostumados a usar na programa��o, como *se**, **enquanto**, **para**,
**arrays*, etc. Eles existem para que o algoritmo seja de f�cil leitura
para qualquer programador, que programe em qualquer linguagem
/"normal"/. Veja o pseudoc�digo do *Insertion Sort*, um algoritmo de
ordena��o de vetores bastante simples:

*para* /j/ 2 *at�* /comprimento do vetor/, *fa�a*

/elemento/ /vetor[j]/

/i/ /j/ - 1

*enquanto* /i/ > 0 e /vetor[i]/ > /elemento/, *fa�a*

/vetor[i + 1]/ /vetor[i]/

/i/ /i/ - 1

*fim-enquanto*

/vetor[i + 1]/ /elemento/

/ /*

fim-para

Se voc� programa em qualquer linguagem, voc� n�o ter� dificuldade em

traduzir esse pseudoc�digo para ela. O pseudoc�digo � sempre uma maneira
bem simples de escrever o c�digo. Veja por exemplo, o mesmo c�digo em C:

for (j=2; vetor[j]!=*NULL*; j++) {

elemento = vetor[j];

for (i = j-1; i > 0 && vetor[i] > elemento; i--) {

vetor[i+1] = vetor[i];

vetor[i+1] = elemento;

Voc� deve ter percebido que ao inv�s de usar tr�s linhas com uma
*declara��o*, um *condicional** *e um *incremento*, eu juntei todos num
s� *for**.* Mas por isso o algoritmo � bem simples e sempre parte do
princ�pio de que a sua linguagem � simples. Veja s� a implementa��o do
c�digo em Pascal e compare-a com a do pseudoc�digo:

for j:=2 to comprimento, do begin

elemento := vetor[j];

i := j-1;

while i>0 && vetor[i] > elemento, do begin

vetor[i+1] := vetor[i];

i := i-1;

end;

vetor[i] := elemento;

end;
Linha por linha ela � exatamente igual! A �nica diferen�a � que o
pseudoc�digo � traduzido... Geralmente os pseudoc�digos s�o parecidos
sempre com essa base e suas implementa��es n�o s�o muito diferentes. E
vai ser sempre dessa maneira que eu vou representar os algoritmos
(usando pseudoc�digos e alguns traduzindo para C para mostrar
implementa��es)

Quando entrarmos no assunto de *ordena��o de vetores*, analisaremos esse

algoritmo do *Insertion Sort* e outros, mas por enquanto vamos ficando
por aqui.

3. Qual a utilidade do algoritmo?

Este artigo � o terceiro da s�rie sobre *algoritmos*. Se voc� ainda n�o

leu os artigos anteriores, sugiro que leia antes de continuar:

Parte 1: O que � um algoritmo?

Parte 2: Como representar um algoritmo?

Vou come�ar este artigo utilizando as palavras do H�lio num coment�rio

no primeiro artigo desta s�rie: 'Algoritmos' � um tema pouco valorizado
por muitos programadores iniciantes, que querem logo botar a m�o na massa.

Quando eu tive a minha primeira no��o do que s�o algoritmos (no dia 12
de julho de 2004, no *Curso de Programa��o** *da* **Olimp�ada Brasileira
de Inform�tica** *na* **UNICAMP*), confesso que fiquei decepcionado e
realmente n�o gostei. Eu j� programava em C e achei um saco o professor
escrevendo no quadro aqueles pseudoc�digos de problemas super simples,
perdendo tempo com isso ao inv�s de programar. Por�m, hoje percebo que
/algoritmos/ s�o muito mais legais (/e importantes/) do que eu pensava.
Claro que para somar dois inteiros n�o h� necessidade de escrever um
pseudoc�digo, mas algoritmos s�o representa��es essenciais para
problemas mais complexos e grandes aplica��es.

Acredito que voc� que j� leu os dois primeiros artigos j� deve saber,
mas n�o custa lembrar: *algoritmo � a rela��o entre entrada e sa�da do
programa, � o rascunho do programa, o projeto**.* E um projeto antes de
colocar a m�o na massa � indispens�vel. *Enquanto a implementa��o � a
fun��o dos pedreiros, o algoritmo � a fun��o dos engenheiros.* Se os
engenheiros n�o existissem, /acho/ que os pedreiros n�o iam conseguir
fazer as casas e os pr�dios que eles constroem hoje em dia!

O algoritmo sempre existe, mesmo que apenas no seu pensamento. A

primeira coisa que voc� pensa quando quer fazer uma aplica��o (a n�o ser
que voc� seja louco) �: *o que � a aplica��o? O que ela vai fazer?* E se
voc� sair implementando uma coisa complexa, voc� vai se decepcionar
depois demorando mais do que o tempo de fazer a implementa��o s� para
limpar o c�digo! Por isso, representar algoritmos complexos � essencial.

E mais... Mesmo se voc� tivesse tempo infinito, mem�ria infinita, etc. e

tal (n�o tivesse necessidade de limpar o c�digo), voc� vai precisar de
um algoritmo pra provar que o seu programa funciona, para se organizar e
para estudar a sua l�gica. Se voc� n�o planejar um algoritmo para o caso
acima, qualquer funcionalidade que voc� queira adicionar no meio, por
falta de projeto e organiza��o, vai demorar bem mais tempo. Por isso,
algoritmo n�o � uma perda de tempo antes da programa��o, mas a
programa��o � que se torna uma perda de tempo quando n�o teve um
algoritmo (ou, um projeto). O livro *Algoritmos: Teoria e Pr�tica*
refor�a essa interessante id�ia na p�gina 7:

Suponha que os computadores fossem infinitamente r�pidos e que a mem�ria

do computador fosse livre. Voc� teria alguma raz�o para estudar
algoritmos? A resposta � sim, se n�o por outra raz�o, pelo menos porque
voc� ainda gostaria de demonstrar que o m�todo da sua solu��o termina, e
o faz com a resposta certa.

Outra utilidade do algoritmo � compartilhar id�ias de problemas

complexos. Todo programador entende um pseudoc�digo e por isso conv�m
muitas vezes apresentar sua id�ia de um programa em forma de um
algoritmo, num pseudoc�digo, ao inv�s de passar um programa implementado
em C para uma d�zia de programadores de VBScript.

Existe uma s�rie de algoritmos comuns que todo programador deve conhecer
(projetos prontos para muitas coisas complicadas que precisamos
implementar no dia-a-dia) e isso � o que vamos come�ar a estudar no
pr�ximo artigo.

4. Analise de algoritmo

*Analisar* um algoritmo � prever o que o algoritmo ir� precisar. �s

vezes o hardware � importante, mas acho que o que acontece com mais
freq��ncia, ao menos em olimp�adas e problemas em casa, � precisarmos
medir o tempo que ele ir� demorar.

Eu explanei em algum dos artigos anteriores que o *tempo de um

algoritmo* depende geralmente do tamanho de sua entrada. Com este
artigo, pretendo explicar como analisamos um algoritmo baseado nesse
tamanho de sua entrada para compar�-lo com outros algoritmos e ter uma
no��o de quanto tempo ele vai demorar.

Para o entendimento ficar mais f�cil, vamos partir do seguinte algoritmo

(que vamos chamar *de **Algoritmo 1**):*

* *

1. *para* /i/ 1 at� /n/, *fa�a*

2. *para* /j/ 1 at� /i/, *fa�a*

3. *imprima* /i/ /j/ /n/

4. *fim-para*

5. *fim-para*

O que este algoritmo faz �, depois de receber a entrada do usu�rio,

imprimir o produto de com todos dois n�meros e , tal que .

Para medir o custo do algoritmo, nossa an�lise consistir� em ver quantas

vezes cada passo � executado. Mediremos o custo de cada linha (cada
passo a ser executado), sempre em fun��o de *n*, que para este algoritmo
� a vari�vel mais importante (ali�s, a �nica vari�vel). Por isso o
pseudoc�digo do *Algoritmo 1* est� com suas linhas numeradas. Vamos
analisar...
*Linha 1:* Ser� executada vezes.

*Linha 2:* Ser� executada vezes.

*Linha 3:* Ser� executada vezes.

*Linhas 4 e 5:* N�o tem custo.

4.1 Por que estes n�meros de execu��o?

Se voc� j� entendeu por que cada passo � executado este n�mero de vezes,
pode pular essa parte (continuar a ler a partir da linha horizontal).

Linha 1

O loop *para* voltar� para si mesmo vezes, isso �, testar� novamente sua
condicional e incrementar� um. Por sempre testar um condicional, no
final ele ter� que testar novamente para dizer que j� passou de . Por
isso, ele ser� executado vezes, ao inv�s de simplesmente .

Linha 2

Este loop *para* ser� executado um n�mero de vezes vari�vel (), que ir�
de a . Portanto, ele ser� executado duas vezes (1 mais "o �ltimo
condicional") no primeiro loop de , tr�s (2 mais "o �ltimo condicional")
no segundo, e por a� vai. Com isso, ele ser� executado o n�mero de vezes
que equivale a soma de a , mais que s�o "os �ltimos condicionais".

Linha 3

Exatamente o mesmo n�mero que a *Linha 2*, mas sem "os �ltimos
condicionais" ().

Imprimir algo na tela pode demorar mais do que fazer uma opera��o, mas a
an�lise de algoritmos � uma coisa bem /r�stica/. Desprezamos todas as
constantes, com isso s� levando a s�rio a informa��o importante: neste
caso, apenas . Ent�o agora, vamos escrever o tempo de execu��o do
algoritmo, que � a soma dos tempos de execu��o para cada instru��o
executada.

/
Os par�nteses n�o s�o necess�rios, mas coloquei para ajudar na
visualiza��o separando o custo de cada instru��o.

Simplificando esta opera��o, teremos:

, uma *fun��o quadr�tica**.*

4.2 Ordem de Crescimento

Como eu j� disse antes, descobrir o custo de um algoritmo � uma coisa

feita sem precis�o, porque para entradas realmente grandes (que s�o
casos onde precisamos do computador!) as constantes n�o importam. Agora
vamos determinar a *ordem de crescimento* de um algoritmo resgatando do
nosso algoritmo apenas o valor mais importante, o maior expoente de
nele, neste caso, . Se tiv�ssemos , por exemplo, tamb�m usar�amos apenas
porque o que multiplica tamb�m � desprez�vel!

Vamos agora aprender como representar o custo desse algoritmo usando

*nota��es assint�ticas* com a ordem de crescimento do algoritmo.

Se voc� n�o entendeu alguma coisa a� em cima, sugiro reler antes de

continuar...

/_

4.3 Nota��es Assint�ticas

Sugest�o

Principalmente para pessoas mais novas, esta parte � cansativa porque

exige bastante conhecimento de matem�tica. Quando eu comecei a aprender
isto, talvez por causa da matem�tica t�o b�sica que � ensinada na
escola, eu n�o entendia nada... Mas s� quero dar uma dica: se voc� n�o
entender direito ou achar muito complicado, pule para a pr�xima linha
horizontal ao inv�s de desistir e dizer que /"algoritmos s�o muito
dif�ceis"/. Tentei fazer o artigo para voc� poder pular essa parte e
mesmo assim n�o parar no estudo dos algoritmos... Depois, com o tempo,
voc� vai aprendendo isso (pe�a pro seu professor de matem�tica dar uma
ajuda).

As nota��es que usamos para descrever o tempo de execu��o de um

algoritmo s�o *cinco**:*

* *

o
 o

Embora essas nota��es sejam conjuntos, usamos o *sinal de igualdade* ()

para expressar que pertence a algum deles, ao inv�s de usar o *sinal de
pertin�ncia* ().

Vou explic�-las, omitindo alguns fatos para tentar facilitar o

entendimento, porque eu acho que analisar algoritmos � meio complicado.
E nessa parte � meio dif�cil p�r did�tica. Mas se voc� realmente se
interessar, voc� pode me enviar um coment�rio pedindo mais um artigo
sobre isso (e eu terei o prazer de at� pesquisar para informar-lhes
mais) ou ent�o leia o /Cap�tulo 3/ do livro /*Algoritmos: Teoria e
Pr�tica**,*/ que acredito que seja bem completo. Gostaria de enfatizar
aqui que /meu objetivo com essa s�rie � tornar uma introdu��o a
algoritmos simples/ e n�o /ser uma refer�ncia/, como � o objetivo, por
exemplo, do livro do /*Cormen [et al]**.*/

A nota��o :

L�-se /"theta de g� de ene"/.

, *se* existem constantes positivas , e tais que para todo .

A nota��o :

L�-se /"� mai�sculo de g� de ene"/. Para quando h� apenas um *limite

assint�tico superior*.

, *se* existem constantes positivas e tais que para todo .

A nota��o :

L�-se /"omega mai�sculo de g� de ene"/. Para quando h� apenas um *limite

assint�tico inferior*.

, *se* existem constantes positivas e tais que para todo .

A nota��o :

*
L�-se /"� min�sculo de g� de ene"/. Para quando h� apenas um *limite
assint�tico superior*, sem permitir que . Utiliza-se a nota��o para
denotar um limite superior que n�o � assintoticamente restrito.

, *se* /para qualquer constante/ , existe uma constante tal que para todo .

A nota��o :

L�-se /"omega min�sculo de g� de ene"/. Para quando h� apenas um *limite

assint�tico inferior*, sem permitir que . Utiliza-se a nota��o para
denotar um limite inferior que n�o � assintoticamente restrito.

, *se* /para qualquer constante/ , existe uma constante tal que para todo .

Podemos criar v�rias compara��es entre estas fun��es, mas isto n�o vem
ao caso. O importante � saber em que nota��o a nossa fun��o se encontra.
Com o tempo vamos compreendendo melhor essas f�rmulas (se voc� est�
boiando, n�o se assuste, eu tamb�m tive muita dificuldade com isso no
come�o).

Vamos relembrar o custo de nosso algoritmo... .

Vamos ver em que nota��o ele pode se encaixar, sabendo que seria a
*ordem de crescimento* (parte importante) do nosso custo; no caso, .

Testamos primeiro se ele encaixa na fun��o . Vamos substituir e (naquela

fun��o ali em cima, onde diz *A nota��o *) pelos valores que conhecemos.

Se dividirmos tudo por , obteremos:

Agora separaremos as inequa��es.

*Inequa��o 1:*

*Inequa��o 2:*

Para satisfazer a *Inequa��o 1*, podemos quase automaticamente perceber

que para qualquer , � v�lido (ora, por mais que chegue perto de 0,
sempre ainda vamos ter a constante 1 adicionada a ele). Para satisfazer
a *Inequa��o 2*, podemos perceber facilmente que para qualquer , �
v�lido (a fun��o s� tende a diminuir a partir que vai aumentando e com ,
). Com isso, agora chegamos as tr�s constantes que precis�vamos.

(o menor valor de ) ; ; .

Logo, conclu�mos que . Uma fun��o que pertence a , tem um *limite

assint�tico superior** e **inferior** *e, portanto, pertenceria tamb�m a
e , mas nem � necess�rio testar os outros valores porque j�
identificamos nossa fun��o como /"theta de ene ao quadrado"/, que � a
fun��o mais "retinha" que podemos esperar.

Bom... Nos pr�ximos artigos, veremos que um mesmo problema pode ter
v�rias solu��es diferentes com custos ainda mais diferentes! Por isso, �
importante sabermos analisar, mesmo que por cima, qual o algoritmo que �
mais eficiente.
*Tiago Madeira - **tmadeira[arroba]gmail.com*
<mailto:tmadeira[arroba]gmail.com>

*P�gina anterior* <algoritmos-primero.shtml> *Voltar ao in�cio do

trabalho* <algoritmos-primero.shtml> *P�gina seguinte*
<algoritmos-primero.shtml>

As opini�es expressas em todos os documentos publicados aqui neste site

s�o de responsabilidade exclusiva dos autores e n�o de Monografias.com.
O objetivo de Monografias.com � disponibilizar o conhecimento para toda
a sua comunidade. � de responsabilidade de cada leitor o eventual uso
que venha a fazer desta informa��o. Em qualquer caso � obrigat�ria a
cita��o bibliogr�fica completa, incluindo o autor e o site Monografias.com.

O maior Centro de Teses, Documentos, Publica��es e Recursos Educativos

da Rede.
Termos e Condi��es </politicas.shtml> | Entre em Contato </contacto.shtml>
� Monografias.com S.A.