Erlang proporciona um mecanismo interessante de representação em formato binário, o que se justifica se lembrarmos que a linguagem foi desenvolvida para se trabalhar com telecomunicações (a linguagem foi desenvolvida pela Ericsson. Nas fontes que consultei existem divergências sobre a origem do nome Erlang. Há alguns lugares que dizem ser a contração de ERicsson LANGuage. Outras fontes afirmam ser uma referência ao matemático Agner Krarup Erlang).

Esse mecanismo de representação binária facilitaria a transmissão e manipuação, em nível de bit, dos dados. Por Exemplo, para se representar uma sequência de bytes em Erlang, envolvemos a em << … >>:

<<1, 77, 32, 88 >>.

Isso representa justamente quatro bytes, contendo os valores decimais: 1, 77, 32 e 88. Se quisermos entrar com os bytes em, por exemplo, hexadecimal, devemos explicitamente indicar a base:

<< 16#1, 16#4d, 16#20, 16#58 >>.

Okay, o leitor diria, até agora não vi nada de diferente em relação à uma lista. Por exemplo, eu poderia simplesmente fazer

[ 16#1, 16#4d, 16#20, 16#58 ].

e tudo daria no mesmo.

A primeira diferença em se usar Binary Sintax em Erlang é que este trunca os valores em 255 (ou 8 bits, FFh, como você preferir enxergar), ou seja, qualquer valor que for colocado acima de 255 ocasionará um overflow, justamente como um sistema difgital puro se comporta. Por exemplo:

<< 257 >>.

retorna:

<<1>>

Isso faz muito sentido, pois estamos trabalhando com bytes diretamente.

Bem, essa foi só uma rápida introdução para que possamos chegar onde eu desejo, que é a notação Binary Sintax do Erlang. Essa notação nos permite trabalhar com conjunto de dados estipulando arbitrariamente o tamanho de cada elemento em bits (isso mesmo, bits, não bytes). Imagine por exemplo que eu quero salvar um conjunto de dados que tem três elementos, cada qual pode ocupar uma faixa bem definida de valores. Com base nos valores máximo eu posso estipular a quantidade específica de bits a serem utilizados em sua representação.

Vamos ver isso de uma maneira mais prática:

Proposta – Representar em uma stream de bits o valor de um pixel que contém as três cores (Red, Green e Blue) em níveis que varias:
0~31 para R
0~63 para G
0~31 para B

Aqui usamos um bit a mais para representar a cor verde, pois o olho humano tem uma maior sensibilidade à essa cor. Perceba que estamos falando em quantidade de bits necessários para representar cada cor, e não quantidade de bytes. Se pretendêssemos usar, por exemplo, uma struct C para representar esse conjunto fariamos mais ou menos assim:

struct RGB{
char r;
char g;
char b;
};

Assim eu aloquei 8 bits para cada cor. O que é completamente desnecessário, pois a se olharmos para a faixa que vada valor deve representar, e cpontarmos quantos bits realmente são necessários, teremos:

Cor     Faixa     Bits
R         0~31         5
G         0~63         6
B         0~31         5
Total                  16

Notamos aqui que não são necessários mais que 16 bits para representar as cores RGB no nosso sistema, porém estamos trabalhando com uma struct de três chars, o que consome 24 bits. Uma alternativa é você representar as três cores em um array de char de tamanho 2, porém caberia a você toda a manipulação dos bits, o que daria um pouco de trabalho (mas nada que um programador competente não resolva em uma tarde).

A grande sacada de se usar Bit Syntax em Erlang é que você pode especificar quantos bits cada elemento deve ocupar, e quando você passa um valor que não cabe naquele elemento, ele se comporta da mesma maneira descrita anteriormente: ocorre-se um overflow. Vamos, utilizando bit syntax, passar os valores de RGB e recupera-los na forma de um stream de 16 bits:

R = 15.
G = 52.
B = 19.
<< R:5, G:6, B:5 >>.

note que a saída foi <<126,147>>, um bit stream de exatamente 16 bits. Podemos agora encapsular isso, e cuidar para que ninguém coloque valores fora da faixa especificada:

-module(rgb).
-export([marshall/3, unmarshall/1]).

marshall(R,G,B) ->
  if
    R > 31 ->
      throw({overlimit, R});
    G > 63 ->
      throw({overlimit, G});
    B > 31 ->
      throw({overlimit, B});
    true -> true
  end,
  << R:5, G:6, B:5 >>.

unmarshall(Binary) ->
<< R:5, G:6, B:5 >> = Binary,
  {R,G,B}.

Salvando esse código em um arquivo de mesmo nome de seu módulo (rgb.erl), vamos entrar no console Erlang e compila-lo:

> c(rgb).
{ok,rgb}

Pronto, agora estamos aptos a usar tanto as funções marshall e unmarshall que empacotam nossos valores RGB em stream de bits e desempacotam esse stream, devolvendo uma tupla com esses valores.

Exemplo:

rgb:unmarshall(rgb:marshall(8,19,30)).

Esse é um exemplo simplório da utilização de bit syntax em erlang, mas já dá pra ter uma pequena noção do seu poder.A idéia é explorar um pouco mais com coisas mais complexas, que provavelmente nos daria muito trabalho implementando em linguagens como C.

Desta vez vamos utilizar uma aproximação silmilar, utilizando algorítmos diferentes que realizam o mesmo propósito porém com eficiências diferentes. Porém a nossa meta neste caso é demonstrar como podemos unir idéias que a princípio parecem desconexas para um mesmo fim, melhorando implementações e nos dando um ganho considerável de tempo.

Formalizando o problema

Uma problema que todo mundo implemente ainda nos primeiros meses de aprendizado de programação é a implementação dos Números de Fibonacci. A definição formal da sequência fibonacciana é a seguinte:

Assim, a série de Fibonacci começa com os dois elementos iguais a 1, posteriormente temos:

Um dos motivos que os professores gostam de mostrar a sequência de Fibonacci no início do aprendizado de programação dos alunos é que a esta sequência, por ser naturalmente recursiva, é facilmente implementável e demonstra ao aluno a idéia básica de recursão. Geralmente a implementação demonstrada pelos professores é similar à seguinte:

def fibo(n):
  if n==0 or n==1:
    return n
  else:
    return fibo(n-1)+fibo(n-2)

Este código é bem simples, e a recusão está bem fácil de se identificar. Porém um dos motivos que eu não gosto deste algoritmo (principalmente para mostrar para programadores que estão começando a aprender) é que este método é extremamente ineficiente. Para exemplificar, na minha máquina (um MacBook) esse algoritmo gastou pouco mais de 1:30 minutos para encontrar o valor do quadragésimo número da sequência, retornando fibo(40)=102334155. O valor está correto, mas o tempo gasto para o seu cálculo apenas reflete a fraquesa de implementação em se tratando de eficiência. Uma implementação iterativa como a seguinte:

def fibo2(n):
	if n==0 or n==1:
		return n
	n -= 1
	previous=1
	current=1
	while n>1:
		previous,current = current, current+previous
		n -= 1
	return current

resolve o mesmo problema proposto para a mesma entrada (n=40) em cerca de 110 ms (no mesmo computador). Vamos rapidamente analizar os dois códigos e tentar entender o porque desta diferença. Se olharmos para a recursão podemos claramente retirarmos a forma básica da expressão de tempo para n=1 ou n=0. Para ambos a a resposta é direta, o tempo gasto sempre será constante, portanto T(1)=t(0)=O(1).

Porém se a entrada for maior ou igual a 2, o custo computacional pode ser representado pela soma dos tempos necessários para o cálculo de f(n-1) e f(n-2). Assim fechamos nossa fórmula recursiva para o primeiro caso em:

Se resolvemos a recursão pela método da árvore de recursão, abrindo a recursão na forma de uma árvore com dois ramos (que são as duas chamadas recursivas), contabilizamos que a quantidade de passos a se executar é proporcional ao resultado de f(n). Em palavras mais simples, a quantidade de passos para se calcular cresce na sequência fibonacciana. Logo:

que, assintoticamente, cresce exponencialmente (a solução desta recursão passo a passo não convém neste post, mas pode ser abordado em um outro momento).

Por fim temos que:

Já no segundo caso a análise é muito mais simples. O nosso algoritmo tem um único loop que corre n unidades, assim temos:

o que significa que a segunda implementação tem comportamento linear. Isso claramente nos responde o porque a segunda implementação (iterativa) é tão mais eficiente que a primeira (recursiva), pois:

Porém essa análiaze nem de logne prova que toda solução recursiva (ou com comportamento recursivo) tem eficiência inferior à uma iterativa (sequer essa é a intenção deste post, lembra?).

Vamos nesse momento reservar essa primeira parte do post e mostrar um segundo caso idenpendente.

Potenciação

Um outro exemplo simples que professores podem adotar para demonstrar recursão é a soluçao de potenciação. A potenciação é simplesmente a multiplicação n vezes de uma base b por ela mesmo. Assim:

   n vezes

Uma implementação simples com recursão segue:

def pow(b,n):
  if n==1:
    return b
  return b*pow(b,n-1)

O bacana é que essa implementação roda em T(n)=O(n), ou seja, linearmente. Mas como nunca devemos nos contentar com o que já temos, podemos pensar em como melhorar essa implementação. A primeira coisa que podemos melhorar é implementar recursão-em-cauda para que o espaço ocupuado em memória não cresça ao aumentar o tamanho de n(Nota: mesmo com nossas implementações estando em Python, o fato de a linguagem suportar ou não a recursão em cauda aqui é desprezado, pois o que nos interessa é a metodologia aplicada na resolução).

def pow2(b,n,acc=1):
  if n==1:
    return b*acc
  return pow2(b,n-1,acc*b)

Mesmo com esse problema resolvido o nosso custo computacional permanece intacto. Para melhorarmos isso podemos recorrer a uma propriedade da potenciação que nos diz que:

O que, por exemplo, nos leva a dividir o cálculo

que gasta 3 multiplicaçoem em

que consome apenas duas (note que o mesmo cálculo 4^2 não precisa ser computado duas vezes). Agora basta chamarmos recursivamente para cada n/2, apenas fazendo uma pequena alteração para os casos de n ser ímpar:

def pow3(b,n):
  if n==1:
    return b

  if n%2:
    h = pow3(b,(n-1)/2)
    return b*h*h
  else:
    h = pow3(b,n/2)
    return h*h

Uma rápida análise deste código nos extrai a forma recursiva do custo computacional desta nova forma:

Essa recursão pode ser facilmente resolvida se você imaginar que a cada vez que você dobra n você incremente em O(1) o valor de T(n). Isso nos leva a uma função logarítmica de base dois:

O que é bacana, pois diminuímos aqui o comportamento assintótico do cálculo da potência de b^n pois:

Nesse nosso segundo exemplo, ao contrário do primeiro, o uso da recursão melhororu bastante o desempenho da nossa implementação. Utilizando a técnica de dividir e conquistar, nós quebramos uma potenciação em duas mais simples de se efetuar, e depois recombinamos o resultado. Porém ainda não chegamos no intuito final desse texto que é a união de técnicas com propósitos distintos para ganharmos em desempenho.

Método de Fibonacci por matrizes

Uma maneira bacana de se encontrar a sequência de fibonacci é analizando a matriz

Se multiplicarmos essa matrix por ela mesmo temos:

e novamente:

e genéricamente:

Agora o interessante para nós é o comportamento da primeira linha da matriz resultado. Chamando

percebemos que após cada multiplicação K recebe o valor dele mesmo mais o de L enquanto L recebe o antigo valor de K. Esse deslocamento de valores é semelhante (ou igual) ao que acontece com a forma recursiva da função geradora da fórmula de Fibonacci. A mesma análise pode ser feita na linha inferior da matriz. Com isso reduzimos a forma fechada da geração de números via multiplicação de matrizes:

ou seja, basta multiplicarmos a matrix geradora por ela mesmo n vezes que obtemos na segunda coluna da primeira linha o valor equivalente a a fibo(n).

Unindo forças

Agora que vêm a pergunta, seria possível aproveitar a nossa função de potenciação para multiplicarmos a matriz geradora a fim de obter o enésimo valor da sequência de Fibonacci? Bem, a nossa função da forma que ela foi concebida não serve para multiplicar matrizes, pois a multiplicação é feita na forma a*b que não é suportada para matrizes (pelo menos não em Python, que é a linguagem que estamos fazendo nossos exemplos). Porém podemos facilmente modificar nossa função para aceitar como terceiro parâmetro a função que deverá ser aplicado ao elemento a ser multiplicado:

def pow4(b,n,f=lambda x,y:x*y):
  if n==1:
    return b

  if n%2:
    h = pow4(b,(n-1)/2,f)
    return f(f(h,h),b)
  else:
    h = pow4(b,n/2,f)
    return f(h,h)

O bacana é que a nossa função continua funcionando para potenciação de números, basta omitirmos o terceiro parâmetro, passando apenas a base e o expoente à função.

Uma implementação de multiplicação de duas matrizes 2×2 é dada a seguir:

def mult_matrix(ma,mb):
  (a,b),(c,d) = ma
  (e,f),(g,h) = mb
  return [[a*e+b*g,a*f+b*h],[c*e+d*g,c*f+d*h]]

e por seguinte, definimos a nossa matriz geradora:

fib_matrix = [[1,1],[1,0]]

Agora basta encapsularmos a chamada da função que faz a chamada da potenciação para o cálculo:

def fibo3(n):
  if n==0 or n==1:
    return n
  return pow4(fib_matrix, n, mult_matrix)[0][1]

Agora com a nossa terceira implementação aplicamos o ganho de desempenho provido pela nossa implementação de potenciação para gerarmos o enésimo número da sequência de Fibonacci, melhorando a complexidade do método de O(n) [bom] para O(lg n) [melhor]. Essa mescla de técnicas nos traz melhorias significativas, que pode se mostrado na prática nesse caso.

Conclusão

Com um comparativo simples, fazendo n=1.000.000 (um milhão), o cálculo de fibo(n) consumiu :

fibo2	1m53.979s (implementação iterativa)
fibo3	0m23.732s (com potenciação recursiva de matrizes)

Por motivos óbvios a primeira implementação não foi avaliada para um n tão alto poi para testes mais simples, como n=40 foram necessários mais de 1 minuto e meio para se computar. E como o comportamento da primeira implementação é exponencial, ao almentarmos o valor de n para pouco mais de 50 unidades, o tempo de execução do nosso algoritmo explodiria (quem tiver paciência, poderia deixar o algoritimo rodando para n com valores elevados, como 100, 200, etc.)

Pretendo posteriormente fazer um comparativo caso a caso das três implementações, mas acredito que com o que equacionamos (e mostramos na prática) como é possível sempre ganharmos um pouco de desempenho se fugirmos um pouco da solução óbvia, e buscarmos por meio mais eficientes, e mesclarmos técnicas, como o que fizemos aqui nessa ocasião, nos aproveitando do ganho na implementação da potenciação para gerarmos números da sequência de Fibonacci.

Todo o código deste post pode ser enconytrado aqui: gist.github.com/972762

Update: Aqui eu fiz o upload de um arquivo contendo a representação em ASCII do 50.000.000-ésimo número da sequência de fibonacci. O arquivo têm pouco mais de 10MB, e não tem muita utilidade… mas caso vocÊ queira baixar, fique a vontade!

Como entusiasta da linguagem Python, tento extrair ao máximo as facilidades que a linguagem me proporciona. Todo mundo que conhece mesmo que seja um pouquinho sabe que uma das grandes vantagens da linguagem são as funções built in que proporcionam, entre outras muitas facilidades, uma simplificação do tratamento de listas.

Trabalhar com listas em Python é extremamente simples (pra quem já usou a STL do C++ sabe bem o trabalho que uma lista pode nos dar!). Mas quando eu comecei a trabalhar com a linguagem (há uns três anos), eu carregava comigo muitos vícios providos dos meus muitos anos programando em C e C++. Veja no exemplo abaixo, o que eu cheguei a fazer no meu início pela linguagem:

vetor []
cont = 0
while cont < 10:
    vetor.append(cont)
    cont += 1

Bem, não precisa ser nenhum sênior na linguagem pra ver que a construção anterior é completamente, digamos, não-pythônica. Isso poderia ser facilmente substituido por um:

vetor = range(10)

Enfim, antes que alguém pense que isso é um post sobre como usar listas em Python (não, isso não um post sobre isso. Caso queira aprender mais sobre o assunto eu sugiro este texto aqui), vamos ao que eu quero falar hoje: List Comprehension.

Em Teoria dos Conjuntos nós temos algumas notações que nos permitem criar conjuntos de elementos, como por exemplo

é  a representação do conjunto de todos os elementos reais maiores que zero, ou seja, todos números reais positivos. Ou por exemplo o conjunto dado por

que é composto por todos os números naturais pares.

De certa maneira, a função Python vetor=range(10) pode ser escrita na notação de conjuntos por

ou seja, k pertence aos naturais e k é menor que 10.

List Comprehension é uma maneira de trazer para a linguagem de programação a notação de conjuntos. Um set de elementos criados por uma list comprehension obedece uma série de parâmetros previamente estipulados. Esses parâmetros têm como princípo impor condições para o nosso set de elementos, a fim de compor, baseado em regras, a nossa lista. Não expliquei nada né?? Então vamos por exemplos. Imagine uma set S que é dada por:

Assim, temos que S é composto por todos os elementos x pertencentes aos números naturais, tal que X<20. Porém, apareceu mais um componente aí na minha lista. Esse componente que aparece antes do pipe é a saída da minha função, ou seja, para cada valor de x que existir, ele inluirá no meu set o valor 2*x. A expressão do exemplo anterior pode ser dividida nos seguintes elementos:

De um forma simplificada, podemos dizer que dado um conjunto de entrada, a variável denotada recebe cada elemento deste conjunto que atende à condição imposta pelo predicado (ou seja, nesse caso, verificar se a variável retirada do conjunto é menor que 20). Uma vez atribuído um valor à variável, é aplicado a essa variável a função de saída, que dá o valor que será colocado na minha list. Simples não? Então qual seria o resultado de S ? Todos os números naturais, menores que 20 e multiplicados por 2…

Ok, muito interessante mas… como coloco isso no código? Se estivessemos falando de linguagem C pura (a qual eu aprendi a programar, e carreguei muitos vícios por muito tempo), o nosso código ficaria parecido com:

int i;
int *v = (int*)malloc(sizeof(int)*20);
for(i=0; i<20; i++)
    v[i] = 2*i;

Programadores em geral costumam carregar vícios, costumes que aprenderam em outras linguagens. Se eu fosse escrever o código anterior em Python nas primeiras semanas em que comecei a aprender a linguagem eu provavelmente não estaria tirando o máximo da linguagem, mas sim simplesmente transcrevendo uma lógica em código.

Escrevendo esse mesmo código, agora em Python, e usando list comprehension teríamos:

S = [2*i for i in range(20)]

O leitor pode facilmente identificar os elementos citados anteriormente no código Python. Por exemplo, o pipe | foi substituído pela cláusula for enquanto o símbolo pertence foi substituído pela cláusula in. Como a função range já nos devolve os números naturais menores que 20, não foi necessário utilizar a cláusula do predicado, mas caso isso seja necessário, basta adicionar um comparador à variável com um if ao final da sentença. Mostrando por exemplos, que fica mais fácil, digamos que em algum momento hipotético possuamos uma lista com os seguintes valores:

S = [2,5,7,98,108]

e desejamos selecionar apenas os valores menores que 50. Para isso podemos fazer:

K = [x for x in S if x < 50]

Note que nesse exemplo o meu conjunto de dados de entrada é a própria lista S, e assim aplicamos um filter no nosso conjunto de elementos. Ora pois, para este fim é mais viável utilizar realmente a função built-in filter que nos dará o mesmo resultado. Mas se repararmos bem, uma list comprehension nada mais é que um gerador de lista que compreende também uma função filter além de uma função map em sua construção. Com essas duas utilidades, você pode, ao construir uma lista, filtrar os dados que você deseja e aplicar alguma função à lista.

Aplicando list comprehension

Uma aplicação que eu achei bem legal de se fazer com list comprehension é a implementação do algoritmo Quick Sort. Apenas para relembrar o funcionamento do algoritmo (caso precise de mais detalhes dê um pulo em alguma referência mais completa), o algoritmo basicamente consiste em estipular um pivot que é um elemento aleatório do meu set e separar este set em dois grupos: um contendo todos os elementos maiores que o meu pivot e outro contendo os elementos menores. Uma vez feito isso, a função é chamada recursivamente para cada sub-set de elementos.

Como list comprehension nos permite facilmente filtrar os elementos de uma lista, criando assim uma nova lista, se eu quiser, por exemplo, selecionar todos os elementos x da minha lista que são maiores que um valor pivot (ou também selecionar os elementos que são menores) eu poderia proceder da seguinte forma:

K = [8, 4, 1, 2, 3, 9, 6, 5, 7] #vetor com elementos dispostos em ordem aleatória
pivot = k.pop() #remove um elemento aleatório de K
less_than_pivot = [x for x in K if x < pivot]
greater_than_pivot = [x for x in K if x > pivot]

Agora bastaria eu chamar recursivamente esta função para os sub-sets obtidos, e concactenar os resultados. O código final ficaria da seguinte forma:

def qsort(v): return [] if v == [] else qsort([x for x in v if x < v[0]]) + [v[0]] \
    + qsort([y for y in v if y > v[0]])

if __name__ == "__main__":
    K = [4, 5, 3, 7, 6, 1, 2, 9, 8]
    print qsort(K)

Poh, legal, bacana, então quer dizer que apenas o Python implementa list comprehension não é? Na verdade várias outras linguagens (principalmente linguagens de alto nível) implementam esta função. O mesmo código acima pode ser implementado, por exemplo, em Erlang usando list comprehension:

-module(sort).
-export([quick/1]).
quick([]) ->
    [];
quick([Pivot|Rest]) ->
    quick([X || X <- Rest, X < Pivot]) ++ [Pivot] ++ quick([Y || Y <- Rest, Y >= Pivot]).

Como podem ver, list comprehension podem nos ajudar em várias ocasiões, basta conhecer um pouco mais as funcionalidades que cada linguagem nos provê, e saber quando usá-las.

Então, baseando nas soluções dadas por Knuth, vamos analizar aqui dois casos clássicos de recursão:

Torre de Hanoy

Um algoritmo clássico e que está presente na maioria dos cursos de computaçãp/programação quando é apresentado ao aluno o conceito de recursão é o algoritmo que resolve o problema da Torre de Hanoy.  Esse algoritmo é usado em cursos de computação devido a sua extrema simplicidade e facilidade de compreensão por parte do estudante.

A sua idéia básica é enxergar a torre de discos como duas torres distintas: uma sub-torre formada por n-1 elementos e uma segunda torre formada pelo n-ésimo (último) disco. Assim devemos mover esta sub-torre para uma casa auxiliar, mover o n-ésimo elemento para o destino e, por fim, mover a sub torre da casa auxiliar para a casa de destino. Cada sub-torre pode ser enxergada como uma nova torre, e aplicada, recursivamente, o mesmo algoritmo, até que cheguemos a uma torre com n=1 elementos. O código a seguir ilustra a sequência de passos necessária para se resolver o problema da torre de Hanoy:

def hanoy(n, origem, destino, aux):
    if n== 1:
        print "Mova disco %i de %c para %c" % (n, origem, destino)
    else:
        hanoy(n-1, origem, aux, destino)
        print "Mova disco %i de %c para %c" % (n, origem, destino)
        hanoy(n-1, aux, destino, origem)
if __name__=="__main__":
    hanoy(3, "A", "C", "b")    #exemplo de como usar

Como eu disse anteriormente, a simplicidade desse código é um dos grandes atrativos para se ensinar recursão.

Porém aqui a nossa questão é outra (tanto porque estamos assumindo que todo leitor que deseja aferir a complexidade de um algoritmo que utilize recursão domine essa técnica). A nossa pergunta é: Qual a complexidade temporal desse algoritmo, ou em outras palavras, A medida que eu aumento a quantidade n de disco, em quanto eu aumento o tempo T(n) de execução do meu código?

A primeira solução, e a mais simples possível, é a aferição empírica: coloco uma variável contanto o número de chamadas que a minha função têm e traço um gráfico da relação número-de-discos X número-de-movimentos:

Uma coisa podemos aferir com total certeza sobre o comportamento deste gráfico: a função que ele representa não é linear! Mas, enfim, qual a função que representa a complexidade deste algorítmo?

Todo algoritmo recursivo tem uma característica comum: um ponto de final de execução. Para a função da torre de Hanoy, o fim da execução é dado para sempre que n=1, assim temos que:

ou

Agora analizemos como se comporta o algoritmo para n=2. Primeiramente o código vai chamar a função (de forma recursiva) para n=1 [linha #5], essa entrada da função faz um movimento [linha #3] e, saindo da função, fazemos mais um movimento [linha #6] e novamente chamamos a função de forma recursiva [linha #7]. Essa segunda chamada recursiva também vai passar como parâmetro o valor n=1, assim mais uma vez será feito um movimento [linha #3, dentro da chamada segunda chamada].

Resumindo, para n=2 fizemos duas chamadas recursivas [linhas #5 e #7]. Como em cada chamada um movimento é feito, temos aí dois movimentos dentro das chamadas recursivas. Além desses dois movimentos, um terceiro movimento é executado entre as chamadas das linha #5 e #7. Assim temos um total de 3 movimentos, ou:

Generalizando a quantidade de movimentos para n=2 temos que ele realiza 1 movimento, mais duas vezes a qauntidade de movimentos para n=1 (devido as duas chamadas recursivas). Assim temos:

Generalizando para qualquer valor de n temos:

Ótimo, retiramos assim a relação da quantidade de movimentos pela quantidade de discos existente no problema. Mas há um porém: e se eu quiser saber quantos movimentos são necessários para mover uma torre com 64 discos por exemplo? Teríamos que calcular , com isso obter e assim por diante até . Um tanto braçal não? Agora imagine que desejamos procurar para um n ainda maior? Assim precisamos colocar essa equação em sua forma fechada:

Por enquanto temos:

Somando 1 em cada lado da equação temos:

Assim podemos dizer que:

Que por extensão também é válido dizer:

Da segunda equação temos:

Assim:

Que por fim nos dá:

Depois de toda essa manipulação ainda não temos uma forma fechada que solucione o nosso problema, mas perceba agora que a relação entre um elemento e o seu antecessor é dada pelo dobro do antecessor. Parafraseando o Donald Knuth: Não é preciso ser nenhum gênio para notar que

Como

Temos então que:

Que, por fim, nos dá a complexidade temporal do algoritmo:

Sim, a ordem do nosso algoritmo é exponencial. Isso explica o porque do nosso gráfico explodir para valores [nem tão] elevados de n.

Recordadno os passos que fizemos para chegar ao resultado, primeiro nós encontramos o ponto de parada do algoritmo, em seguida aferimos quantos movimentos [aqui figurado como o nosso custo] são feitos para o caso mais simples (n=1). A partir disso encontramos a solução iterativa do custo computacional do nosso algoritmo. Com a solução iterativa em mãos, lançamos mão de técnicas de manipulação para encontrar a forma fechada da função que corresponde ao seu custo. E assim chegamos finalmente na complexidade relacionada ao método.

Perceba que por momentos lançamos mão de induções para chegar a forma fechada da solução.

Algoritmo de Ordenação QuickSort

Um outro algoritmo que é muito estudado pelos iniciantes de computação é a solução de ordenação Quick Sort. Existem pelo menos dois bons motivos para se estudar o Quick Sort: 1 – ele é um algoritmo bastante eficiente de ordenação, 2 – é um algoritmo relativamente simples de se implementar e de entender e 3 – é mais uma oportunidade de se mostrar o funcionamento de recursão, desta vez em um algoritmo que é bastante usado em diversas aplicações.

A idéia básica do quicksort está em subdividir os valores do set de elementos a serem ordenados em duas partes: uma inferior a um valor denominado pivo e outra maior que este valor. Em seguida, o set de valores é disposto de uma maneira em que os valores a direita deste pivot sejam de valor inferior a ele, e os a esquerda de valor superior. Por fim a função é novamente chamada (de forma recursiva, note) para estes dois grupos de elementos. Note aí a recursão, que é o nosso alvo neste momento (para mais informações sobre o funcionamento do algoritmo Quick Sort consulte seu livro de algoritmos preferido!).

Existem várias maneiras de se aferir a complexidade de um algoritmo como esse. Vamos apresentar duas, cada uma assumindo certas particularidades na implementação do algoritmo.

Solução #1:

Como no primeiro exemplo (Hanoy) vamos primeiramente estipular qual seria o custo para um valor n trivial. Assim, não é difícil enxergar que:

Neste caso, o primeiro custo é, dado o pivo, fazer a partição do meu set de dados em duas partes. Ora, dado um conjunto de n valores, para dividi-lo em duas partes eu preciso fazer até n+1 comparações:

Como o valor do pivo pode ser qualquer um dos elementos do set, temos que estimar a média de todas as possibilidades de partições possíveis. Por exemplo, se o meu set contém 10 elementos, temos as seguintes opções de partição: (5,0),(1,4), (2,3), (3,2), (1,4) e (0,5). Note que cada uma dessas partições vai chamar, recursivamente, a função para cad um dos subsets criados. Cada um desses subsets têm um custo proporcional a quantidade de valores que ele contém. Assim temos que o valor médio entre todas as possibilidades é dada por:

Explicando um pouco melhor o que fizemos anteriormente, note que a quantidade de elementos de cada subset é que determina qual vai ser o custo de processar cada um destes. Emfim, tirando a média entre todas as possibilidades temos o valor médio do custo para todas as possibilidades.

Por fim, somando as duas partes temos que o custo C(n) para executar esse código é dado por:

Uhm, bacana, agora além de ser iterativo, temos um somatório aí dentro. Bem, vamos com calma. A primeira coisa a fazermos é retirar a recursão desta expressão. Para isto temos que sumir com a variável n dentro de C(n-k+1). Para isto vamos abrir o somatório para um valor dado de n como por exemplo n=3. Assim temos:

Uhm, agora ficou fácil. Perceba que cada elemento repete duas vezes, assim podemos simplificar para:

Que nos dá:

Retirando a constante 2 de dentro do somatório, e reescrevendo a função temos:

Bem, agora que conseguimos retirar a recursão que estava dentro do somatório, temos que dar um jeito de sumir com esse somatório. Vamos para isso tentar manipular a função a fim de tira-la. Multiplicamos primeiro ambos os lados por n:

Agora substituindo n por n-1:

Subtraindo uma pela outra a fim de eliminar o somatório:

Assim temos:

Voltando agora ao nosso querido Donald Knuth, no livro Concrete Mathematics ele nos passa uma maneira de reduzir uma sentença da forma

em

[para mais detalhes sobre essa transformação vide o livro Concrete Mathematics, Donald Knuth, pág 27]

Assim, reescrevendo a nossa função nesta forma temos:

Mas somatório denovo??? Sim, mas note desta vez que não temos mais uma recursão dentro da nossa função. Note também que essa somatória tem uma cara de alguma série harmônica.

Assim, vamos manipular esse somatório para deixa-lo como uma série harmonica:

Da série harmônica temos que:

Assim, tomando apenas o elemento de maior índice (para conta da notação Big O):

Que, finalmente, nos dá:

Solução #2:

Depois de provarmos matematicamente a ordem deste algoritmo, ficamos mais a vontade de inferir uma análize um pouco menos formal. Vamos analizar agora com base apenas no fluxo do algoritmo, sem demais formalidades.

Uma escolha aleatória do pivo divide em duas partes o nosso set de elementos. Supunhamos agora, num caso ótimo, que o elemento escolhido como pivo seja o elemento central. Assim dividimos o set em dois grupos de iguais quantidades. Dividindo constantemente cada subset em duas partes iguais, fica fácil calcular o número máximo de divisões que teríamos.

Por indução, suponha que nosso set tenho 32 elementos. Se seguirmos constantemente dividindo-o por dois temos: 1*32, 2*16, 4*8, 8*4, 16*2 e por fim 32*1. Note que o crescimento é similar a uma árvore binária, onde cada nó se divide em dois ramos, e o custo total é análogo a altura desta árvore.

Como a altura de uma árvore é dada, em aproximação livre, por , e sendo este valor análogo à quantidade de chamadas recursivas que o algoritmo irá fazer, e sendo também que, para cada chamada, toda a execução dentro da chamada é executada em O(n), temos:

Que, por fim, nos dá:

Assim concluimos a análize da complexidade de dois algoritmos recursivos. Espero que tenha sido útil o post.

Dando continuidade ao texto sobre Paralelismo, esta segunda parte trata na prática um pouco como funciona um programa paralelo usando OpenMP. Vale lembrar que este texto foi escrito no início do meu trabalho de pesquisa, e estou o reciclando por desativar o antigo blog. Espero que gostem:

Nada como um projeto novo para entusiasmar no aprendizado de tecnologias diferentes. Já fazia algum tempo que eu estava com vontade de começar a trabalhar com programação paralela, mas sem algo concreto para dar o impulso inicial estava complicado.

Relembrando o algorítimo de cálculo do valor de pi com base em uma série de somas:

soma = 0
para cada i, enquanto i < LIMITE:
   soma += 4/(i*4 + 1)
   soma -= 4/(i*4 + 3)
   i += 1
fim para

Resolvi implementar esse pequeno código para testar uma primeira implementação usando o OpenMP. Na minha pesquisa de paralelismo de simulação de dinâmica dos Fluidos (CFD) vou usar a linguagem Fortran, por ser uma linguagem diretamente voltado à cálculos matemáticos. Porém, com uma rápida pesquisa sobre OpenMP, descobri que ela é suportada também pela linguagem C++, uma velha amiga, que eu sempre gostei muito de usar. Pensei então “por que não estudar como usar o OpenMP em ambas?”. Então, na medida do possível, pretendo repetir todos os experimentos e exemplos nas duas linguagens.

Como discutido no post anterior, a idéia do OpenMP é ser uma API que faz o gerenciamento dos Threads, distribuindo-os entre os núcleos/processadores disponíveis no sistema. Esse gerenciamento faz com que o programador não precise se preocupar com o sincronismo entre os threads, nem com a escalabilidade dos sistema.

Porém, o OpenMP é uma API, ou seja, uma ferramenta. E uma ferramenta só faz o que o programador a instrui fazer. Basicamente fica ao encargo do programador definir quais regiões serão paralelizadas, quais serão executadas de forma serial e quais são as variáveis compartilhadas e privadas de cada thread. O programador faz uso de algumas diretivas que são incluídas no código. Essas diretivas são avaliadas pelo pré-processador do OpenMP, e este faz o trabalho de dividir as tarefas entre os núcleos/processadores.

Tomemos como base a implementação em linguagem C do programa de cálculo do PI:

#include
#define NUM_PASSOS 20000000

int main(){
 double pi = 0;
 int i;

 for(i = 0; i < NUM_PASSOS; i++){
   pi += 4.0 / (4.0*i + 1.0);
   pi -= 4.0 / (4.0*i + 3.0);
 }
 printf("-> %f\n",pi);
return 0;
}

O mesmo exemplo pode ser visto em Fortran aqui

Compilando esse código com o GCC, sem nenhuma flag de otimização e executando o código em um pc com processador intel ia32 com GNU/Linux o programa precisou de quase 1 segundo para executar:

[john@vaio rascunhos]$ time ./a.out
-> 3.141593

real    0m0.906s
user    0m0.870s
sys     0m0.000s

Apenas para efeito de comparação, o código escrito em Fortran, compilado com o compilador ifort da intel, precisou de apenas 0.010s para executar. Um ganho de quase 90% que o Fortran proporciona, mas isso é assunto para um outropost.

O motivo pelo o qual esse código consumiu tanto tempo para ser executado está no número de repetições dentro do laço. A priori, em todo laço existe uma grande possibilidade de paralelizar o processo, dividindo as tarefas internas do laço entre os vário núcleos do meu sistema multiprocessado. Neste exemplo simples, percebam, a complexidade do meu algoritmo é linear, e relativa ao número de iterações. Em caso de complexidades mais críticas (quadrática, por exemplo), a paralelização do código traz benefícios ainda mais evidentes.

Devido a problemas estruturais (minha máquina não é multi-core) realizei o mesmo experimento com o auxílio do meu amigo Maluta em um Mac Mini que rendeu o seguinte resultado (não paralelizado, apenas para servir de base comparativa para o código paralelizado):

$ time ./a
-> 3.141593

real 0m0.686s
user 0m0.634s
sys 0m0.002s

Para paralelizar o código devemos indicar, por meio de diretivas, quais trechos o compilador deve utilizar a API OpenMP para dividir em threads. A primeira diretiva apresentada é a diretiva OMP PARALLEL. Essa diretiva indica qual parte do código vai ser dividida (fork). O final de um trecho paralelo é sinalizado com um OMP END PARALLEL:

...
... trecho serial
...
OMP PARALLEL
...
... trecho paralelizado
...
OMP END PARALLEL
...
... serial novamente

Desta maneira, tudo que está no trecho paralelizado vai ser executado simultaneamente por todos os threads do sistema. Devemos salientar que as diretivas sofrem leves variações do C++ para o Fortran. Essas diferenças serão notadas nos códigos, mas a semântica é a mesma para ambos os casos.

Outra diretiva, senão a mais usada, é a que indica que um loop deve ser paralelizado. A diretiva OMP PARALLEL FORou OMP DO são usadas para indicar que um laço deve ser dividido. Como o intuito desse blog não é ser um tutorial de OpenMP ou uma referência formal, mais detalhes sobre a sintaxe de cada diretiva pode ser encontrada no site oficial do projeteo OpenMP.

Paralelizando o laço principal (e único) do meu programa, temos o seguinte código:

#include
#include
#define NUM_PASSOS 20000000
<pre>int main(){
	double pi = 0;
	int i;
	#pragma omp parallel for
	for(i = 0; i < NUM_PASSOS; i++){
		pi += 4.0 / (4.0*i + 1.0);
		pi -= 4.0 / (4.0*i + 3.0);
	}
	printf("-> %f\n",pi);
return 0;
}

O equivalente em Fortran pode ser encontrado aqui.

Para compilar o código usando o GCC e o OpenMP, é necessário usar a flg -fopenmp:

gcc -fopenmp <source> [-o nome]

O resultado da execução deste código foi:

$ time ./b
-> 2.897633

real 0m0.544s
user 0m1.041s
sys 0m0.005s

Bem, o tempo de execução para o código linear foi de o.686s e no paralelo foi de 0.544s, ou seja, um ganho de aproximadamente 20%, porém, o meu resultado foi PI = 2.897633 ????????????? Alguma coisa não funcionou corretamente neste modelo de paralelismo.

A resposta é simples: quando o código foi paralelizada, cada parte da execução foi feita em um núcleo diferente. Assim, ao se fazer o join, as duas partes não são somadas, como deveriam. Em outras palavras, as variáveis Soma nesse caso estão separadas, e não compartilham o mesmo dado. O que devemos fazer nesse caso é forçar a união desses valores ao fim da execução dos threads. Para isso usamos mais uma diretiva, a diretiva REDUCTION:

#include
#include
#define NUM_PASSOS 20000000

int main(){
    double pi = 0;
    int i;
    #pragma omp parallel for reduction (+:pi)
    for(i = 0; i < NUM_PASSOS; i++){
        pi += 4.0 / (4.0*i + 1.0);
        pi -= 4.0 / (4.0*i + 3.0);
    }
    printf("-> %f\n",pi);
    return 0;
}

Novamente, o resultado em Fortran se encontra aqui.

Compilando e executando o código, temos a seguinte saída:

$ time ./a
-> 3.141593

real 0m0.433s
user 0m0.634s
sys 0m0.003s

Agora o nosso resultado confere com o valor de PI e o ganho em desempenho é de aproximadamente 36% comparado com o seu equivalente serial.

Com isso já temos base suficiente para brincar um tanto bom com paralelismo, e testar em outros algoritimos.

Há algum tempo eu escrevi um texto sobre como funciona (informalmente) o paralelismo de códigos. Como estou querendo condensar meus tópicos em um único blog, vou reproduzí-lo aqui. Espero que gostem:

Sem delongas, na computação de alto desempenho o tempo é um fator determinante no resultado final de um trabalho. Em um campo onde a complexidade dos algoritmos tende a subir, e o tempo gasto para se executar um algoritmo engrandece junto à sua complexidade, distribuir as tarefas entre vários processadores e vários núcleos é uma maneira de se ganhar um tempo precioso na execução das tarefas.

O princípio básico é extremamente intuitivo: O seu código é dividido em partes que podem ser executadas separadamente, e cada uma dessas partes são enviadas à diferentes núcleos/processadores do seu sistema. Simples assim.

Como todo computólogo já está cansado de saber, a teoria pode até ser simples, mas na prática as coisas são um pouco diferente. Como o intuito desse blog é ser direto, vamos explicar por exemplos. Tomamos o código abaixo que tem como função calcular o valor de Π (pi). Esse cálculo pode ser feito baseado em uma série dada por :

Assim sendo, o algoritmo que resulta na soma pode ser descrito por:

soma = 0
para cada i, enquanto i < LIMITE:
   soma += 4/(i*4 + 1)
   soma -= 4/(i*4 + 3)
   i += 1
fim para

Ao final da sequência, a variável soma compreende o valor de pi.

Dentro desse loop, que deve ser repetido diversas vezes, são executadas duas principais funções, que geram a soma total do valor de pi. Imaginemos agora que fosse possível dividir essas duas somas, cada um para um núcleo de um processador:

Processador 1:
soma1 = 0
para cada i, enquanto i < LIMITE:
   soma1 += 4/(i*4 + 1)
   i += 1
fim para
Processador 2:
soma2 = 0
para cada i, enquanto i < LIMITE:
   soma2 -= 4/(i*4 + 3)
   i += 1
fim para

E ao final de ambos os processamentos, os valores das duas variáveis são adicionados, resultando em um único valor:

soma = soma1 + soma2

Com isso nosso algoritmo de soma foi dividido em dois, e cada um direcionado para um núcleo independente. Isso faz com que as duas somas de cada loop ocorram “simultâneamente”, ou seja, em paralelo. Com isso, o ganho hipotético em tempo de execução do nosso algoritmo paralelizado é de cerca de 2x.

Esse técnica de dividir e reagrupar (fork & join) é a base de como o OpenMP trabalha para paralelizar os códigos.

A filosofia de se utilizar fork/join consiste em um thread principal, que dispara as threads que vão trabalhar em paralelo. Ao final do trabalho dessas threads em paralelo, o fluxo é reunido (join) o processamento continua de forma serial. No nosso exemplo do cálculo do Pi, essa sequência poderia ser enxergada da forma:

thread principal-> dispara os dois loops em threads diferentes para o cálculo das somas[1,2]
fork-> cada thread calcula sua soma, simultaneamente
join-> os valores das somas são somados, resultando no valor final do meu cálculo

Para este exemplo simples, não fica muito complicado para o programador escrever duas rotinas de soma dentro deloops e disparar a execução dos threads, aguardar o resultado das somas e uní-los. Porém, temos alguns pequenos problemas:

• O código não é maleável em relação a quantidade de núcleos/processadores a serem utilizados.
• O programador deve se encarregar de resolver todos os problemas como concorrência, deadlock, join, etc.
• Não há como saber quantos núcleos eu tenho disponível.
• O código não fica transparente ao programador.
• Com o aumento do código, a manutenção da paralelismo torna-se impraticável.

Como visto, usar threads diretamente resolve o problema, mas está longe de ser uma solução prática e escalável para paralelismo de códigos.

Para resolver esse problema, são empregadas APIs para paralelizar o código. Essas APIs nada mais fazem do que resolver para o programador quais trechos serão divididos, em quantos threads serão divididos e encarregar de enviá-los para seus respectivos núcleos/processadores. A API OpenMP é uma das soluções para se trabalhar com paralelismo de código, e foi a minha escolha para uma primeira abordagem com o assunto.

É quase que uma unanimidade: alunos de graduação/pós, desenvolvedores independentes e programadores em geral não se sentem atraídos pela área de estudo de complexidade de algorítmos. E, pra não perder o costume, eu sou um dos que fogem a regra e gostam de junções de matemática e programação (não que eu seja bom nisso, mas eu gosto mesmo assim!). Enfim, uma maneira bacana de se enxergar a matemática aplicada à análise de desempenho algorítmico é usar diferentes algoritmos que resolvam o mesmo problema, e ir aferindo o ganho no desempenho ao longo de seu desenvolvimento. Há alguns poucos dias eu estava brincando no SPOJ quando me deparei com um problema que quase todo programador já teve que resolver uma vez: determinar a primalidade de um número. Esse exercício é interessante pois quase todo curso/apostila/livro acaba usando como exemplo.  Eu resolvi dar uma pequena modificada pra adaptar o problema à proposta deste post, então, reformulando a questão, vamos ao nosso problema:

Dado um número n, determinar todos os números primos p sendo 1 ≤ p ≤ n

Em outras palavras, nosso programa deverá encontrar todos os número primos menores ou igual a n. Como o nosso intuito é justamente analizar o desempenho do algorítmo em diferentes situações, nada mais natural do que começar por um método simples (e não muito eficiente, como você verá posteriormente), o brute-force. Neste método o nosso algorítmo irá verificar para cada elemento do nosso conjunto de entrada (um array de n números, indo de 1 até n) se este elemento é ou não divisível pelos elementos de valor inferior a ele no conjunto de entradas: Seja k o meu conjunto de número, e supondo que desejamos encontrar todos os valores primos menores ou igual a 20 (n =20), prosseguiriamos da seguinte maneira: 1 e 2 são primos (da definiçào de números primos) 3 não é multiplo de 2, então é primo 4 é multiplo de 2, então não é primo 5 não é multiplo de 2 ou 3 ou 4, então é primo … E assim nosso algorítmo caminharia até o vigésimo elemento, verificando a divisibilidade de cada elemento pelos seus antecessores até 2. Em linhas gerais nosso algorítmo ficaria como o seguinte:

var n: int
array k: int
array _k: int
k = [i from 2 to n]
para cada elemento i de k:
   _k = [i from 2 to i]
      para cada elemento j de _k:
         se i%j==0:
            i não é primo

Uma implementação deste algoritmo em Python:

def primo(v):
    k = [i+1 for i in range(v)]
    resposta = []
    for i in k:
        if i == 1 or i == 2:
            resposta.append(i)
            continue
        k_test = [j+2 for j in range(i-2)]
        v = True
        for j in k_test:
            if not i%j:
                v = False
                break
        if v: resposta.append(i)
    return resposta

if __name__=="__main__":
    print primo(20)

Apesar de funcionar bem para faixas pequenas de valores, como n=20, a medida que crescemos a faixa de valores que nosso programa deve percorrer, o tempo de execução para encontrar o resultado cresce vertiginosamente. Por exemplo, para calcular todos os números primos de 1 à 10000 [dez mil] esse algoritmo gastou em minha máquina algo em torno de 15 segundos:

real    0m15.694s
user    0m13.536s
sys     0m0.033s

Para n=100000 o algoritmo for abortado após 20 minutos executando, e não havia ainda terminado a sua tarefa. Mas o que faz esse algorítmo ser tão ineficiente? Bem, fazendo uma análise superficial de como ele funciona, podemos ver que para cada elemento a verificar, o nosso programa faz tantas comparaçòes quanto o valor do elemento. Assim, em um exemplo, para verificarmos todos os números primos menores ou iguais a 8, fariamos a seguinte quantidade de verificações:

n | comparações 2 | 0 3 | 1 4 | 2 5 | 3 6 | 4 7 | 5 8 | 6

Ou seja, a quantidade total de verificações necessárias para o nosso programa determinar os números primos menores ou igual a 8 é a soma das comparações para cada elemento do meu vetor de possibilidades. Em  uma maneira mais geral, a ordem do algoritmo pode ser dada por:

(1)

Onde :

(2)

Como essa série se trata de uma progressão aritmética simples, a reduzimos para:

(3)

Que Resolvendo nos dá:

(4)

Por fim, o que nos interessa na notação de ordem em Big-Oh é o termo de maior ordem, assim temos:

(5)

O que isto pode nos dizer deste algoritmo? Bem, pra começar podemos compreender que a medida que o meu valor de n vai aumentando, o tempo total de processamento vai crescendo em potência de dois em relação a n. Ou seja, o meu tempo de processamento cresce gigantescamente mais rápido que o tamanho do meu vetor de testes. Podemos verificar o comportamento desta curva aumentando gradativamente o valor de n e traçando a curva n vs O(n):

Como podemos perceber ao plotar o gráfico, a curva de crescimento do tempo de execução segue um comportamento conveniente à uma função quadrática. Isso nos indica que a análise da complexidade do nosso algoritmo para calcular todos número primos em uma faixa de 1 a n está correta.

Para prosseguirmos com nosso estudo em cima dos algoritmos, vamos fixar o valor de n=100000 [cem mil elemento]. Com esse valor, vamos fazer algumas alterações no algoritmo, mas ainda mantandeo a sua essência, e ver o quanto conseguimos melhorar o seu desempenho.

Para o algoritmo na forma como foi implementado acima em python, para se calcular todos os números primos de 1 até cem mil foi gasto pouco mais de 42 minutos (isso mesmo, minutos!).

O nosso algoritmo como está descrito faz a verificação de primalidade, dividindo e verificando o resto de cada número por todos os seus antecessores.  Porém, não é preciso muita matemática para percebermos que para verificar a primalidade de um número k qualquer, não é necessário verificar o seu resto de divisão por números próximos ao seu valor.

Colocando em exemplo, imagine que desejamos calcular a primalidade do número 11. Não faz sentido eu verificar  o resto da divisão de 11 por 10, 9, 8, etc. O maior número que poderia ser um divisor inteiro de 11 é √11. Então, ao invéz de calcular a o resto da divisão por cada elemento inferior a 11, vamos calular apenas o resto da divisão de 11 por cada elemento meor ou igual a √11. Perceba que com isso diminuimos a faixa de valores que o nosso algoritmo vai percorrer dentro de cada loop interno, vamos verificar como fica a o algoritmo e sua complexidade com essas alterações?

import math
def primo(v):
    k = [i+1 for i in range(v)]
    resposta = []
    for i in k:
        if i == 1 or i == 2:
            resposta.append(i)
            continue
        k_test = [j+2 for j in range(int(math.sqrt(i)))]
        v = True
        for j in k_test:
            if not i%j:
                v = False
                break
        if v: resposta.append(i)
    return resposta

if __name__=="__main__":
    print primo(100000)

Bem, com apenas essa simples alteração o tempo para calcular os primos entre 1 e cem mil caiu de 42 minutos para apenas 6.33 segundos (sim leitor, segundos!). Assim como fizemos com a primeira implementação do algoritmo, vamos novamente traçar a curva correlacionado tempo de execução e tamanho do meu vetor de entradas:

Como podemos verificar no gráfico acima, o comportamento do nosso algoritmo agora se assemelha um pouco mais a uma função linear do que a uma função quadrática. Porém, só uma análize matemática pode nos dar a certeza de não estar equivocando quanto a essa conclusão [N.R. Quem leu este post antes da revisão vai entender que eu errei na hora de analizar matematicamente a complexidade deste algoritmo, pois troquei as bolas entre os limites do somatório e a variávei do somatório]. Podemos comprovar isso matematicamente, fazendo novamente a análise da ordem do algoritmo:

Da equação (1), assumimos agora que a quantidade de verificação para cada n_ésimo elemento muda. Agora, ao invés de nossa iteração assumir todos os valores de inferiores a i, o valor deste limite superior é truncado em √i:

(6)

Assim como anteriormente, expandindo nossa série:

(7)

E posteriormente resolvendo como uma PA simples:

(8)

Por fim, resolvendo a multiplicação entre os termos e tomando o elemento de maior ordem temos:

(9)
Diferente do que foi presumido, a ordem do nosso algoritmo não se torna linear, mas mesmo assim temos um ganho considerável sobre o primeiro caso, principamente para valores grandes de n.

Porém a medida que crescemos muito o tamanho de n novamente encontramos gargalos no tempo de execução do nosso programa. Por exemplo, se tentamos calcular todos os números primos menores ou igual a 1 milhões, o tempo de execução do nosso algoritmo novamente vai ficar demasiadamente grande (em torno de 4 minutos), mesmo sua complexidade sendo melhor que a anterior. Agora imagine que desejamos encontrar a resposta para n=100 milhões. Com esse algoritmo que escrevemos, ou temos uma ótima máquina e muito tempo disponível, ou desistimos de usá-lo. Por isso podemos pensar em novas alterações para o algoritmo.

A primeira modificação que fez diferença no nosso código foi a de diminuir a faixa de valores que o algoritmo verificaria a possível multiplicidade de um dos números da nossa sequência. Agora vamos imaginar um panorama diferente: Assuma que vamos procurar todos os números primos entre 1 e 10. A princípio nosso array k de possibilidades pode ser descrito como:

k = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]

Assim, assumimos por definição que 1 e 2 são primos. Para determinar se outro número é ou não primo, devemos verificar a divisibilidade deste novo número pelos demais números já encontrados. Em outras palavras, sabemos que nenhum número múltiplo de 2 é primo, então poderíamos simplesmente não verificar a primalidade de todos os números múltiplos de 2. Para indicar isso, percorro minha lista a partir do elemento 2 de 2 em 2, substituindo o seu valor (que é múltiplo de 2) por um valor neutro. No caso vamos utilizar o 0 [zero]:

k = [1, 2, 3, 0, 5, 0, 7, 0, 9, 0]

Prosseguimos tomando o próximo número não-zero da lista e substituindo todos os seus múltiplos pelo elemento nulo. Nesta nossa segunda passagem o valor tomado é o 3:

k = [1, 2, 3, 0, 5, 0, 7, 0, 0, 0]

E assim prosseguimos, até o final da lista. Assim que tomarmos o último elemento da lista, teremos uma lista composta de números primos e valores nulos. Basta agora retirar todos os valores nulos e temos nossa lista de números primos:

k = [1, 2, 3, 5, 7]

Como no caso anterior, não é necessário fazer o teste para todos os elementos da lista. Sendo uma lista de, por exemplo, 100 valores, no pior caso, quando vamos comparar a primalidade do centésimo elemento, é trivial demonstrar que o maior valor possível de um número inteiro que multiplique outro inteiro para formar 100 é 50*2, porém os múltiplos de 2 j foram excluídos da nossa lista, então decairíamos para 25*4, porém todo múltiplo de 4 também é multiplo de 2, então decairíamos para 20*5, porém todo número múltiplo de 20 também é múltiplo de 10, o que por fim nos leva a 10*10. Como este é a nossa última possibilidade de combinação de inteiros cujo quadrado vale 100, truncamos o valor máximo que vamos tomar para efetuar as multiplicação em 10, que é √100.

Em outras palavras, o valor máximo assumido para fazer a multiplicação para retirar elementos do nosso vetor de possibilidades de tamanho n será sempre √n .

Assim, nosso algoritmo toma a seguinte forma:

array k: int
var j:int
k = [from 2 to n]
j = 2
enquanto j menor ou igual a raiz(n):
   retira todos os múltiplos de j do vetor
   j recebe o próximo elemento de k

Se você entendeu o funcionamento deste algoritmo parabéns, você acaba de aprender o Crivo de Erastótenes. Pra ser sincero, a primeira vez que cheguei nesse algorítmo por indução lógica, fiquei maravilhado com a sua simplicidade de funcionamento. Depois, quando descobri que ele já existia, fiquei num misto de frustação, por descobrir que era algo que já era mais que consolidado (Erastótenes viveu entre 276a.c. e 195a.c.) e felicidade, por chegar sozinho a um algoritmo tão importante e estudado. Enfim, eu estava apenas uns 2200 anos atrasado…

Implementando este algoritmo em Python, com algumas pequenas melhorias:

import math
def prime(v):
    k = range(v+1)
    i = 2
    result = []
    raiz = math.sqrt(v)
    while i <= raiz:
        j = i
        if k[j] != 0:
            while j <= v-1:
                j += i
                if j <= v: k[j] = 0
        i += 1
    for i in k:
        if i:
            result.append(i)
    return result

if __name__ == "__main__":
    prime(10000000)

Pode parecer surpreendente a primeira vista, mas esta nova implementação resolveu os números ímpares para n = 10 milhões em apenas 21 segundos. Vale lembrar que na nossa primeira implementação precisamos de 12 segundos para resolver para n = 10 mil, e como o algorítimo era quadrático, abortamos o teste da tentativa de chegar a n = 100 mil aos 20 minutos, sem sucesso.

Com os mesmos 21 segundos necessários para se calcular os primos menores ou igual a 10 milhões, na nossa segunda implementação, conseguimos alcançar n=250 mil elementos. Ou seja, não há dúvidas que esta implementação é muito superior em questão de desempenho que as anteriores, mas a pergunta é: como quantificar esse ganho de desempenho? A análise da complexidade deste algoritmo é um pouco mais complexa, por isso vamos por partes:

Primeiro, vamos aferir empiricamente o seu comportamento. Como já fizemos outras duas vezes vamos executar o programa para diferentes valores de n:

A princípio o resultado da relação tempo vs tamanho parece ser linear, então vamos verificar realmente se este é linear através de uma análise diretamente no algoritmo.

Tomemos como referência um a execução do algoritmo para um n=100. Vamos verificar manualmente, em caa passagem, quantas comparações é feita:

Na primeira passagem temos nosso vetor completo:

K= [1, 2, 3, 4, 5, 6, 7, 8, 9 ... 99, 100]

Para eleminar todos os elementos múltiplos de 2 fazemos 50 inferências, ou seja 100/2

passo 1 = 100/2

Para eliminarmos agora os múltiplos de 3 fazemos 100/3 inferências:

passo 2 = 100/3

O terceiro passo a princípio deveria ser a retirada dos múltiplos de 4. Porém, como todo múltiplo de 4 também é múltiplo de 3, essa passo se torna desnecessário. Então seguimos para o próximo da lista, ou seja, retirarmos os múltiplos de 5:

passo 3 = 100/5

E, por consequência:

passo 4 = 100/7

O próximo elemento da lista seria o 11, porém este é maior que a √100, então paramos nossa verificação aqui.

Assim, para encontrarmos o resultado para n=100 executamos a seguinte quantidade de passos:

(10)

Generalizando a expressão acima, temos que o numerador é sempre o tamanho n do meu vetor de possibilidades, e o denominador é o meu p_ésimo número primo. Temos também que o último elemento é √n_ésimo elemento:

(11)

Apenas colocando n em evidência, temos:

(12)

A essa série de somas de frações dos números primos é dado o nome de Série Harmônica dos Inversos dos Primos. Assim temos que essa soma pode ser dado pelo somatório para todo p primo menor ou igual a √n:

(13)

Desta série temos:

(14)

Por fim, tomando o elemento de maior ordem temos:

(15)

Com isso provamos que a ordem do algoritmo é, ao contrário do que presumimos a partir do gráfico traçado, não linear.

Aqui eu disponibilizo o código do mesmo algoritmo escrito em linguagem C. Este codigo demorou no meu computador 2.4 segundos para calcular todos números primos para n=10 milhões (contra 19 segundos do mesmo algoritmo escrito em Python). Vale ressaltar que se vc retirar o printf que imprime os valores e contabilizar o apenas o tempo de encontrar a resposta, o tempo de execução cai abaixo de 1 segundo. Fica para quem quiser testar, ver quanto tempo demora para achar os primos para n=1 bilhão.

Para caráter de comparação, o meu computador que usei para rodar os testes foi:

Sony Vaio
Processador: Pentium M 1.73GHz, Centrino, 1 núcleo, 32 bits
1GB de memória RAM
SO: Arch Linux 32 bits

IBM PC-AT - Compudar com o qual eu tive meu primeiro contato com o mundo da informática

Logo em seguida comecei a usar um poderosíssimo IBM 286, equipado com um disco rígido de 250MB e rodando o fantástico MS-DOS 6.22. Hoje em dia não uso mais os sistemas da Microssoft, mas devo muito do meu aprendizado ao MS-DOS. Escrever arquivos de lote (.bat, lembra?) era comigo mesmo. Formatar disquete, jogar Prince Of Persia, brincar no Star Print… como eu me divertia com um computador que sem internet, ou melhor, sem interface gráfica! Enfim, o computador era aquilo, e ponto final. Minha maior decepção com aquele 286 foi quando descobri que não poderia rodar o jogo da Tv Colosso (lembra? Priscila, capaxão, Jota Efe…). O motivo? precisava de uma placa gráfica e um mouse (sim, eu nunca havia usado mouse até então).

Bem, o próximo passo foi um computador que marcou época para mim: UIS-PC 486 (UIS era uma cópia dos IBM PC, assim como muitos outros). Enfim eu estava alinhado ao topo da tecnologia (pelo menos a disponível no Brasil). Era um computador com 16MB de memória RAM e, pirem, 900MB de disco rígido!! Imagina lotar 900MB numa época em que os Sistemas Operacionais eram vendidos em disquetes e internet era algo que vc leu numa revista, e que, um dia, vc vai pra Fenasoft ver como funciona!

Com esse 486, além de finalmente conseguir jogar Tv Colosso e ver pela primeira vez uma interface colorida, eu vi algo que me deixou maravilhado. Esse algo atendia pelo nome de Windows 3.10, e era a maior maravilha que eu já havia visto até então! Paintbrush, navegador de diretórios gráfico (sim, diretórios, o termo pasta só viria com o Windows 95), joguinhos como Sokoban, Duke Nuken, DOOM, Prince of Persia (dessa vez colorido) entre outros.

Tela Colorida!! Uma das grande novidades do meu UIS 486

Foi nessa época que eu frequentei meu primeiro curso de informática, [re]aprendi a usar o DOS (já era tão íntimo, que omitia metade do nome), usar o edit, mudar o prompt de comandos. Conheci lá o Excel, o Access, Label, vi uma impressora colorida (HP580c), descobri que não precisaria de um Zip Drive para transferir um arquivo maior que 1,4MB (usando compactação fracionada), dentre outras coisas. Hoje quase extintos, os cursos de informática no começo da década de 90 eram um frenesi sem tamanho. “Se você não faz um curso de inglês e um de informática, você é analfabeto”, diziam então. Conheci pessoas que foram influentes na minha escolha pela informática. Enfim, estava definitivamente no trilho da Informação Automática.

O 486 me trouxe para um mundo que era totalmente novo, mas isso não chegava nem perto da maior descoberta da minha vida geek até então (estavamos aí por volta de 1995). Em um dia de estudo na biblioteca municiapl da minha cidade (não, não haviam PCs lá em 1995), eu me deparei com um livro de eletricidade voltado para o público infantil. Lei de Ohm, circuito de chave e lâmpada, resistor, etc.. Sempre tive uma atração por ciências, principalmente eletrônica, mas foi algo no fim do livro que me chamou a atenção: uma série de comandos que pareciam uma receita de como calcular a corrente em cima de um resistor. Algumas palavras eram conhecidas por mim (DO, PRINT, IF…). Nunca havia visto programação aantes, no máximo scripts de lote no DOS, mas eu não tive dúvida, sabia que aquilo era UM PROGRAMA DE COMPUTADOR!!!

Procurei ajuda pra saber como colocar aquilo para funcionar (acredite, em 1995 e morando numa cidade de 8 mil habitantes, foi um parto conseguir alguém que pudesse me dar um norte). Enfim, um conhecido do meu professor de informática me apresentou um ‘programinha’ muito parecido com o Edit, mas que tinha a fonte de outra  cor. Esse programa era o QBasic, que vinha junto ao MS-DOS. Enfim eu era apresentado ao meu primeiro compilador e à minha primeira linguagem de programação. Daí pra frente, tudo que eu aprendia de matemática virava programa de computador. Fórmula de Báskhara, regra de três, cálculo do IMC… Tudo virava ‘software’.

Depois desse 486 eu tive alguns outros computadores (duron, atlon…). Hoje uso um vaio de 2006, mas que rodando um bom Arch Linux deixa muitos Quad Core no chinelo. Tenho um celular hoje com muito mais capacidade de processamento que aquele meu 486, e com mais que o dobro de capacidade de armazenamento, mas pra mim aquele 486 foi um marco, algo que mudou minha vida, sem demagogia ou pieguisse.

Desde aquele programa em Basic pra calcular a corrente em um resistor tive contato com muitas outras linguagens de programação e script (C, assembly,  Java Script,  C++, Java, Visual Basic, Python, Ada, e até Fortran, que comecei a estudar exatamente hoje). Mas mesmo não escrevendo mais nada nessa linguagem, Basic é uma das minhas favoritas. Não pela capacidade, mas sim por gratidão.

E assim se constrói um programador, com curiosidade e vontade de aprender. Daí pra encarar a engenharia foi um pulo, mas muita coisa interessante acontecendo.

Mas como agora tenho internet para pesquisar, e uma boa GUI para fazer um front-end, deixe-me voltar ao trabalho, porque muita linha de código há de passar pelo compilador ainda…

A idéia desse blog é compilar informações sobre TI, engenharia (elétrica e da computação) e, lógico, programação. Colocar no papel (ePaper) um pouco do que eu absorvo no meu cotidiano de engenheiro e estudante.

Espero estar atualizando constantemente esse espaço, que eu não caia no auto-esquecimento!