Realidade fantástica

Um ser humano adulto gasta algo como 100W apenas para manter-se dormindo (metabolismo basal). Esse número por si só já é impressionante, mas quando o comparamos ao sol é que algo surpreendente aparece.

O sol tem uma massa na ordem de 10³⁰kg e uma luminosidade na ordem de 10²⁶W. Isso significa que ele produz algo na redondeza de 10^-4W/kg, enquanto os seres humanos estão mais perto de 1W/Kg.

A conclusão simples é a de que um ser humano irradia cerca de 10 mil vezes mais calor que uma massa equivalente do sol irradia.

Para nos diferenciar dos outros seres vivos, criamos muitos objetos, utilizamos veículos, iluminamos as noites e aclimatamos nossas casas. De acordo com segunda lei da termodinâmica, os sistemas fechados tendem ao equilíbrio. Isto é, as diferenças de temperatura desaparecem e o sistema torna-se homogêneo com o tempo. A vida acelera esse processo e o ser humano o industrializa!

Para criar um pouco de ordem em nossos lares, exportamos muito caos para o meio-ambiente. E como há cada vez mais gente no planeta, há cada vez menos espaço para o caos que criamos. Se os pólos estão derretendo é porque o homem está cumprindo seu papel de quebrar os gradientes e homogeneizar a temperatura no sistema (mais ou menos) fechado que é a terra.

Só precisamos agora decidir se isso nos convém.

Power Sort em Java

Pesquisando uma maneira de ordenar números sem usar ifs, acabei tropeçando no Power Sort (e aqui e aqui).

Quando finalmente resolvi escrevê-lo em Java, percebi que era uma variação do Counting Sort. Com quase sete bilhões de pessoas na terra, é difícil ter uma idéia original. De qualquer forma, o Power Sort é um caso especial muito interessante do Counting Sort, porque:

• Usa pouquíssima memória;
• É ainda mais rápido e
• Não precisa de ifs!

O Counting Sort usa um array enquanto o Power Sort usa uma ou duas variáveis numéricas. Por isso, o Power Sort fica restrito a conjuntos menores de dados (para não provocar um overflow).

O código abaixo é o de um Counting Sort muito simples. Ele não considera números negativos e faz a ordenação no mesmo array que recebe.

public class CountingSort {

  public static short[] sort(short[] in) {
    int[] order=new int[32768];
    for(int i=0;i<in.length;i++) {
      order[in[i]]++;
    }
    int index=0;
    int n=0;
    while(n<in.length) {
      while(order[index]==0) {
        index++;
      }
      for(int i=0; i<order[index]; i++) {
        in[n+i]=(short)index;
      }
      n+=order[index];
      index++;
    }
    return in;
  }

}

A idéia é simples. Os shorts positivos vão de 0 a 32767, então o array order representa quantas vezes cada número apareceu em in. Como o índice de order já representa a posição de cada número, só preciso copiar as casas maiores que zero de volta para o array original (as que tem zero representam números que não estão em in).

O interessante desse algorítmo é que ele só precisa olhar para os dados uma vez; ele não precisa de comparações; e tampouco faz trocas. O que ele produz é uma espécie de transformada dos dados.

E o desempenho é excelente. O gráfico abaixo mostra uma comparação com o Quick Sort (através do método Arrays.sort())

No eixo vertical estão os tempos em milissegundos e no eixo horizontal estão as quantidades de elementos ordenados. Testei de um em um milhão até quarenta milhões.

Quatro dimensões em duas

O gráfico do último artigo tinha três dimensões (população, renda e longevidade) comprimidas nas duas dimensões de uma imagem. Neste, vou adicionar mais uma: educação.

O eixo horizontal representa as populações. Portanto, as maiores cidades estão mais à direita. O eixo vertical representa a renda. Logo, as cidades mais ricas estão mais altas que as mais pobres. A longevidade apareceu como cor: quanto mais claro o círculo, mais experiente a população.

Como todas as cidades foram representadas por círculos com o mesmo raio (6 pontos), resolvi usar o tamanho de cada círculo para indicar o índice de educação. A diferença entre o maior e o menor índices é de 0,188. Para simplificar, simplesmente multiplico a diferença entre cada índice e o menor (0,763) por 100. O resultado são raios entre 4 e 18 que, não sendo proporcionais, pelo menos realçam as diferenças.

A consulta é a seguinte:

select 'fill(0,'||w||',0);ellipse('||x||','||y||','||d||','||d||');' 
from (  
  select trunc(log(10,habitantes)*100)-300 x,
         500-trunc(avg(renda)*500) y,
         trunc(avg(longevidade-0.651)*1000) w,
         trunc(avg(educacao-0.763)*100) d
  from municipios
  group by trunc(log(10,habitantes)*100)-300
)
order by d desc

Usei verde para tornar o gráfico mais interessante. Além disso, ordenei os índices em ordem descendente para que os círculos maiores não fossem desenhados sobre os menores.

O resultado é a imagem abaixo:

Aparentemente, a educação melhora a renda. Ou talvez seja o contrário.

Renda e longevidade

Depois de gerar um gráfico para relacionar renda com população das cidades gaúchas, resolvi adicionar mais uma dimensão: a longevidade.

Para demonstrar a longevidade, resolvi usar cor. No gráfico anterior, usei linhas para mostrar o nível de renda. Neste, usei círculos. As alturas refletem a renda, como no gráfico anterior, e a cor indica a longevidade da população.

select 'fill('||w||');ellipse('||x||','||y||',6,6);' from (  
  select trunc(log(10,habitantes)*100)-300 x,
         500-trunc(avg(renda)*500) y,
         trunc(avg(longevidade-0.651)*1000) w
  from municipios
  group by trunc(log(10,habitantes)*100)-300
)

Como a longevidade varia de 0,651 a 0,879, usei a diferença entre cada índice e o mínimo para realçar as diferenças. Caso contrário, todas sairiam com um cinza parecido e o gráfico não seria nada interessante.

A consulta produz linhas com o seguinte formato:

fill(117);ellipse(72,176,6,6);

E o resultado é a imagem que segue:

 

Parece-me que quanto maior a cidade, maior deve ser a renda para que aumente a longevidade.

Processando...

Nos anos 1980, Logo era usada para ensinar matemática e programação para crianças. As que tomaram gosto pela coisa devem agora estar brincando com Processing, caso não tenham crescido nessas três décadas.

Graças a uma exibição interessantísima, resolvi provar um pouco desse novo brinquedo. Construída sobre Java, a linguagem aparentemente não acrescenta grandes coisas. Mas as aparências enganam muito!

Comecei buscando um conjunto de dados interessantes. Encontrei uma tabela de desenvolvimento social dos municípios do Rio Grande do Sul. A consulta abaixo gera comandos que uso no Processing para criar um gráfico.

select 'line('||x||',500,'||x||','||y||');' from (
  select trunc(log(10,habitantes)*100)-300 x, 500-trunc(avg(renda)*500) y
  from municipios
  group by trunc(log(10,habitantes)*100)-300
)

Para que a imagem não ficasse muito grande, comprimi os índices de renda (que variam de 0 a 1 com 3 casas de precisão) em 500 valores. O gráfico que quero gerar relaciona renda per capita com número de habitantes. Para gerar o eixo dos habitantes tirei o logarítmo do número de habitantes e o multipliquei por 100. Assim, tenho coordenadas que variam de 300 (para cidades com milhares de habitantes) até 600 (para cidades com milhões de habitantes). Eu tiro a média da renda e agrupo por ela porque pode haver mais de uma cidade com uma determinada ordem de grandeza de habitantes.

O objetivo da consulta é gerar uma lista de comandos desse tipo:

line(55,500,55,211);
line(108,500,108,174);
line(100,500,100,192);
line(35,500,35,231);
line(123,500,123,195);

Claro, preciso de um pouco mais. Mas Processing facilita tanto a brincadeira, que só preciso do seguinte para completar o meu programa:

size(350,400, JAVA2D);
background(#ffffff);
fill(0);
//Comandos do select
saveFrame("/tmp/idh.png");

O resultado é a imagem abaixo.

Tudo indica que quem quer ficar rico deve procurar uma cidade maior e que quem quer se divertir deve aprender Processing.

Alíquotas contínuas para o Imposto de Renda

A tabela do Imposto de Renda é uma criatura estranha. Em nome da curiosidade matemática, bem que a Receita Federal poderia esclarecer os cálculos que amparam os números.

A tabela abaixo mostra as bases, as alíquotas e as diferenças entre as faixas.

Base (R$)	Diferença para base anterior (R$)	Alíquota (%)	Diferença para alíquota anterior (%)
0	0	0	0
1.499,15	1.499,15	7,5	7,5
2.246,75	747,60	15	7,5
2.995,70	748,95	22,5	7,5
3.743,19	747,49	27,5	5

Então, exceto pela  diferença entre as bases primeira e zerésima, há uma diferença de cerca de R$750 entre elas. E exceto pelas última e pela penúltima alíquotas, há uma diferença de 7,5% entre elas.

A regressão linear mostra que a reta que melhor descreve o crescimento das alíquotas é a de inclinação 0,007 (a cada real, a alíquota cresce 0,007%). Para o primeiro real da última base, por exemplo, essa reta produziria uma alíquota de 26,20% (3743,19*0,007).

O gráfico mostra as alíquotas e a tendência delas (em preto). Porque a escala não é igual nos dois eixos, a linha preta parece muito mais inclinada do que de fato é (eis uma preciosa lição sobre como mentir com gráficos).

O problema de usar essa reta, evidentemente, é que as pessoas pagariam mais impostos e não haveria faixa de isenção. Mas é possível usar a reta a partir de um valor máximo de isenção e até um limite razovável de alíquota. Sem uma alíquota máxima, as pessoas começariam a pagar mais de 100% sobre os valores acima de R$14.285,71.

E como seria calculado esse imposto? Com triângulos, claro!

Ganhando x, calcula-se o imposto assim:

(x²*0,00007)/2.

Considerando uma faixa de isenção f, o cálculo seria:

 (x²*0,00007)/2-(f²*0,00007)/2 ou [(x²-f²)*0,00007]/2.

Um valor hipotético de R$4.000,00 seria tributado em R$407,22 pelas alíquotas normais e em R$486,50 pela alíquota contínua. O valor é maior, porque enquanto as alíquotas permanecem estáveis entre bases no cálculo normal, com a alíquota contínua ela é sempre um pouco maior para cada real adicional (ou mesmo a cada centavo).

Com uma alíquota máxima, o cálculo seria um pouco mais complicado. Se a alíquota máxima for fixada em 40%, o primeiro valor a atingi-la será R$5.714,28 (chamarei isso de M). Então, quem ganhar um salário S acima disso, pagará:

[(M²-f²)*0,00007]/2 + (S-M)*0,40

A primeira parte é constante e podemos reduzir a conta a uma expressão mais simples:

R$1.069,35 + (S - R$5.714,28)*0,40

Para um valor hipotético de R$10.000,00, o imposto seria de R$2.783,64 e, como esperado, um tanto maior que os R$2.057,22 do cálculo normal (se limitássemos a alíquota em 27,5%, então o imposto devido seria de R$2.149,71 e muito mais próximo ao cálculo normal).

Adotando uma alíquota contínua, seria preciso reduzir o ângulo de ataque, já que o próprio fato de ser contínua compensaria as alíquotas menores nos salários mais baixos. Além disso, se há justiça no fato das alíquotas serem progressivas (eu acho que sim, mas isso é tema para outro debate!), uma alíquota contínua seria ainda mais justa.

Claro, alguém pode achar que uma alíquota logarítma seria ainda mais justa, mas isso merece seu próprio artigo!

Trânsito gaúcho II

Sem muito esforço, é possível perceber que ter um carro é muito caro. Baratinho mesmo é andar de táxi.

Eu, por exemplo, estou a 6km do meu trabalho, uso o transporte coletivo e deixo o carro em casa. Todos os dias, portanto, percorro 12km. Em um ano de trabalho, devo percorrer algo como 2.760km (estimo umas 46 semanas de trabalho). Consumindo cerca de 10km/l (o carro não rende muito no centro) a R$2,60 o litro, eu gastaria R$717,60 em combustível.

O seguro adiciona cerca de R$1.600 ao custo de passear de auto. Os impostos, mais uns R$600. Já se foram R$2.917 antes mesmo que eu considerasse a manutenção. Por sorte, o carro é dos bons. Mesmo assim, já precisei trocar os pneus e a bateria em 2 anos de uso (comprei o carro usado). Em manutenção, ele deve consumir uns R$600 por ano, por enquanto. Já são R$3.517 e eu estou sendo otimista nas minhas contas.

Andando de lotação, gasto R$1.840 por ano. A diferença pode parecer razoável, mas eu ainda nem considerei a depreciação e os juros perdidos!

Investindo o preço do carro na poupança, eu ganharia uns R$1.850 em juros por ano. Isso já pagaria a lotação e o principal se manteria igual. Mas ter carro é muito pior que guardar o dinheiro sob o colchão. Em dois anos, ele se desvalorizou cerca de R$3.500 (ante o valor inicial de R$30.000).

Então, a diferença entre manter o meu carro e guardar o dinheiro na poupança é de mais de R$14.200 em dois anos! Isso significa que cada viagem para o trabalho custaria, na realidade, R$15. Dá para ir de táxi. Indo de lotação, eu embolsaria R$22 todos os dias sem fazer nada. Percebe-se logo que um casal, no lugar de ter dois carros, pode considerar ter um motorista e um único veículo.

Deve ser por isso que os motoristas gaúchos estão tão nervosos!