Um milhão, um mil e um ou um milhão mil e um?

Para os preguiçosos:

O projeto de que trato aqui é um conversor de números para sua representação "por extenso". Se você chegou aqui e não quer ter o trabalho de ler, apenas achar o código, siga este link: código (ou acesso o projeto no google code). Se, por outro lado, estiver em busca de explicações para fazer o seu próprio conversor ou curioso sobre como este conversor aí em cima funciona, leia o resto deste post.

Ábaco

Para os curiosos:

O título é esquisito, mas a dúvida era essa. O problema surgiu quando, num dos relatórios do sistema, o cliente exigiu que os valores fossem escritos de forma numérica (fácil, o NumberFormat dá conta que é uma beleza) seguidos do valor por extenso. Pensei com meu botões: não tem problema, TODO MUNDO já precisou disso um dia, deve ter DÚZIAS de conversores para números por extenso vagando pelo labirinto de Falken. Basta escolher o mais bonitim e boas!

Na verdade a tarefa nem era minha. Caiu pra mim quando surgiu o primeiro bug. A classe que tinham usado funcionava bem, contanto que o número fosse redondo ou pequeno. "Um milhão de reais" ele disse quando pedi pra converter 1.000.000,00. Mas logo depois me cospe "Um milhão e três de reais" pra 1.000.003,00. Hein? Mas peraí, isso eu conserto, vá... Só que o próximo número piorou: "Um milhão e seiscentos e cinquenta mil e novecentos e dez reais". Pera lá! Tem E demais aí!.

A primeira coisa que pensei foi em achar outro conversor. Doce ilusão. Existir até existem. Vários (ou melhor, várias cópias do mesmo, já que parecem ser todos baseados no mesmo código original). Mas nenhum funciona.

Quer dizer, funcionam... Se você usar os números de teste que o autor usou! (Quem gosta disso pode fazer disto um "caso" para test-driven design, ou o que valha). Saindo um pouco do que o autor tinha em mente, a coisa desanda.

Nesse ponto eu não tinha mais escolha: teria de implementar o meu próprio conversor. Bom, que os outros estavam errados eu sabia, mas e qual a forma correta de se escrever por extenso? Depois de muita discussão e nenhum acordo, decidimos: Vamos consultar uma gramática!Cheque

Na biblioteca, pegamos logo 3 gramáticas. Nenhuma, claro, concordava com a quantidade de "e" que o sujeito usou. Alias, nenhuma delas concordava entre si. Uma, a mais antiga, pregava o uso de vírgulas a torto e a direito:

um bilhão, cento e vinte milhões, duzentos e três mil, cento e quarenta e sete.

A outra era categórica: depois de mil não! Só depois dos "ãos" é que tem vírgula:

um bilhão, cento e vinte milhões, duzentos e três mil cento e quarenta e sete.

E por último, uma que se dizia de acordo com o novo acordo ortográfico (que não tratou nem de números nem de vírgulas, mas que de alguma forma afetava a opinião do autor a respeito) abominava vírgulas:

um bilhão cento e vinte milhões duzentos e três mil cento e quarenta e sete.

Assim fica difícil, né? Em nosso auxílio veio uma ótima e hiper didática revisora de texto que passava pelo local:

Vírgulas servem para separar os elementos numa lista. No caso dos números, use para separar cada grupo de unidade, milhar, milhão, etc. (nesse ponto a gente, das exatas, anota: uma vírgula a cada potência de 1000). Mas elas não são absolutas, e podem ser omitidas se for para aumentar a clareza. Pense na clareza do texto e escolha a forma que melhor lhe convém. Depois de escolhido o melhor jeito, procure uma gramática que concorde com você e use ela como bibliografia!

Pra mim, esse conselho foi genial. E de certa forma resolveu nosso problema: bastava escolher o mais fácil de implementar e depois procurar uma gramática que nos apoiasse.

Acabei me guiando por 8 regrinhas, que definiram como implementar meu conversor:

  1. números abaixo de 20 tem nome próprio;
  2. de 21 a 99 os números são formados por DEZENA "e" UNIDADE (exemplo: "trinta e cinco");
  3. dezenas redondas não tem nada depois (20 -> "vinte", e não "vinte e zero");
  4. 100 tem nome próprio: cem;
  5. números maiores que 100 são compostos por CENTENA "e" DEZENA ["e" UNIDADE];
  6. acima de 1000 agrupa-se os números em blocos de 3 dígitos (potências de 1000), que são representados como se fossem números menores do que 1000 acrescidos do sufixo representando a potência de mil apropriada (mil, milhão, etc);
    1. os grupos são concatenados por vírgula;
    2. A ultima concatenação é feita por "e" ("um milhão e 200 mil");
    3. A ultima concatenação é omitida (ou substituída por vírgula) caso o ultimo grupo seja maior que 100 e não seja múltiplo e 100 ("mil[,] duzentos e cinquenta")
  7. o "um" em frente ao descritor de grupo "mil" é opcional e deve ser parametrizável ("mil e um" e "um mil e um" são igualmente aceitáveis);
  8. Ao acrescentar a unidade (por exemplo "reais") usa-se o prefixo "de" antes da unidade caso o último sufixo seja de milhão ou maior ("dez milhões de reais", mas "dez mil reais").

Código

Com essas regras a implementação foi quase direta. Primeiro criei uma função para as unidades:


        String unidades(int n) {
                return UNIDADES[n];
        }

Em seguida as dezenas:


        String dezenas(int n) {
                if (n < UNIDADES.length) return unidades(n);
                int unidade = n % 10;
                n = n / 10;
                return DEZENAS[n] + " e " + unidades(unidade);
        }

depois tratei a exceção da regra 3:


        String dezenas(int n) {
                . . .
                String unidadeStr = "";
                if (unidade != 0) {
                        unidadeStr = " e " + unidades(unidade);
                }
                return DEZENAS[n] + unidadeStr;
        }

E seguindo as regras uma a uma cheguei no resultado final, que pode ser visto no google code. Ainda não está perfeito, e ainda quero brincar bastante com esse conversor, então deixem suas sugestões,seja aqui, seja como "bug" no google code, que eu implemento, caso dê tempo (e ânimo).

CLT x PJ

O Coragi da experilmes perguntou como calcular se valia a pena mudar de um emprego PJ pra um CLT. Como a conta não é fácil, fiz essa planilha ai em baixo, que está aberta pra quem quiser editar em: http://spreadsheets.google.com/ccc?key=pkGIIoRl9u7Dhu_UoUDcfOg

(Atenção: ao editar diretamente no google docs, os dados estarão visíveis para todos, cuidado ao inserir dados confidenciais).

Ou pra quem quiser fazer o download nos formatos:

  • ODS (Open Office/BROffice)
  • XLS (Excell)

A planilha calcula IRPF, INSS, férias e 13o salário automaticamente, ainda calcula o desconto de 20% na base de calculo do IRPF, considerando o desconto da declaração simplificada. Não incluí FGTS pois nem todos consideram isso uma vantagem. Quem baixar as versões XLS e ODS poderá ver como é feito o cálculo.

Porque o google erra as contas?

O Joel mandou um mail hoje perguntando:

Tem alguma boa explicação pra 399999999999999-399999999999998 no google retornar 0?
se 399999999999999-399999999999997 é igual a 2 e 399999999999999-399999999999999 é igual a zero (por sinal, como deveria).

Pro que eu respondi, assim por alto:

Erro de precisão. Ele não trabalha com precisão arbitrária (número infinito de dígitos) e converte isso daí pra:

(3,99999999999999 * 10^14)  - (3,99999999999998 * 10^14), e representa esses caras em binário, com, digamos 32 bits. Aí, em binário, a diferença entre esses caras fica na 33a casa, mas a diferença entre 399999999999999 - 399999999999997 fica ainda na 32a (a diferença é o dobro, logo, uma casa antes em binário 🙂 ).

Por isso o primeiro dá errado e o segundo não.

No email eu dei uma resposta até curta, porque não achei que fosse algo tão importante! Mas em pouco tempo a jess me manda no google chat:

5:18 PM jess.listas: Obrigada =)
5:19 PM me: por?
jess.listas: Relevar o grande mistério da humanidade. Me encaminharam um e-mail seu explicando porque o google erra em algumas contas com numeros grandes

Não sabia que a repercussão da minha resposta ia ser tão grande, então resolvi logo escrever um post a respeito. O Problema que acontece com o google chama-se:

Erro de precisão

E pode acontecer com qualquer um... Quer dizer... Com qualquer sistema digital. O lance é o seguinte: Computadores, e sistemas digitais em geral, representam o número usando bits. Cada sistema pode ter seu padrão, mas o número de bits que se reserva pra representar um número é limitado. Já ouviu falar de sistemas de 16, 32 ou 64 bits? Pois então, esses são os tamanhos que são reservados para armazenar um número inteiro. Em geral, se você tenta enfiar[foot]Eu ia dizer xuxar mas quem não é mineiro não ia entender[/foot] um número maior que isso dentro do inteiro, ele simplesmente não aceita e dá erro. Outros sistemas simplesmente ignoram o erro e "comem" um pedaço do número, e você fica com um "restolho" inútil que não te serve pra nada, sem nem mesmo saber disso.

Pra evitar esses problemas, ao invés de usar números inteiros, alguns sistemas usam "números de ponto flutuante", ou "números reais". Ao invés de armazenar 399999999999999 como 399999999999999, armazena-se 399999999999999 como 3,99999999999999 times 10^{14}. As casas depois da vírgula que não couberem dentro do tamanho estipulado são simplesmente descartadas. E é isso que o google faz[foot]Ou pelo menos deve fazer[/foot], e é por isso que vemos esses erros. Pra dar um exemplo prático, vamos usar um sistema com, digamos, 4 bits. Nesse sistema, vamos subtrair alguns números e ver no que dá:

frac{begin{array}{cr} & 19 \ - & 18 end{array}}{begin{array}{cr} = & 1 end{array}}

Bom, 19 em binário é 10011 e 18 é 10010. Ambos tem mais de 4 bits, então eles serão representados como 1,001 times 2^{4} e 1,001 times 2^{4} respectivamente. Mas, veja bem! Ao eliminar os últimos bits, eu eliminei exatamente o que os números tinham de diferente. Agora ao efetuar a subtração tenho:

frac{ begin{array}{cr} & 1,001_{b} times 2^{4} \ - & 1,001_{b} times 2^{4} end{array} }{ begin{array}{cr} = & 0,000_{b} times 2^{4} end{array} }

Aí vem a outra pergunta:

Porque então 399999999999999-399999999999997 deu a resposta certa?

Essa pode parecer mais difícil, mas tem exatamente a mesma explicação. em binário, 2 ocupa uma casa a mais do que 1: 2 em binário se escreve 10 enquanto 1 se escreve apenas 1. Isso quer dizer que, se eu estou "no limite" de casas decimais, o número 2 consegue ficar dentro da minha precisão, enquanto o número 1 já não consegue mais. Com o nosso exemplo, usemos 17 ao invés de 19. Bom, 17 em binário é 10001, e nossa conta com 4 bits fica assim:

frac{ begin{array}{cr} & 1,001_{b} times 2^{4} \ - & 1,000_{b} times 2^{4} end{array} }{ begin{array}{cr} = & 0,001_{b} times 2^{4} end{array} }

Ajustando o expoente temos que 0,001_{b} times 2^{4} = 1_{b} times 2^{1} = 10_{b} , ou seja, 2.

Então, munidos dessa informação, podemos viajar ainda mais e descobrir

Quantos bits o Google usa para representar números reais?

Como vamos fazer isso? simples. Sabemos que 399999999999999-399999999999998 dá erro, enquanto 399999999999999-399999999999997 não dá. Com isso sabemos que 399999999999999 tem exatamente um único bit a mais do que a precisão que o google usa. Basta então descobrirmos quantos bits a representação binária de 399999999999999 usa, e esse será nosso npumero mágico de bits. Então vamos lá. Segundo minha calculadora do linux, 39999999999999910 = 101101011 1100110001 0000011110 1000111111 11111111112. Contando os bits temos 49 bits. Parece um número estranho, afinal eu falei de 16, 32 e 64. De onde veio esse 49?

Bem, em primeiro lugar, o bit mais significativo (i.e. o bit mais a esquerda) não precisa ser armazenado: ele é sempre 1[foot]Já ouviu falar de zero a esquerda? Pois é, não existe zero a esquerda, e como em binário só existe 0 ou 1...[/foot]. Assim, baixamos pra 48. Um número par pelo menos, mas cadê o resto? Bom, a potência que eu representei antes "a parte" precisa ser armazenada em algum lugar. Os bits que faltam pra completar 64 são os bits que eu uso pra armazenar o expoente, ou potência. Assim, 48 bits representam a "mantissa" e os 16 bits restantes representam o expoente[foot]Como esses valores não correspondem ao padrão da IEEE eu suponho que por algum acaso ou mistério da natureza, os números não estão sendo normalizados como deveriam, e por isso usam menos do que os 52 bits do padrão.[/foot].

Conclusão

Não sei bem que conclusão tirar do fato de termos apenas 48 bits. Preciso estudar melhor o padrão IEEE 754 pra entender isso. De qualquer forma, uma conclusão fica latente:

A calculadora do google não usa python!!!

Isso porque, em python os números tem precisão infinita, e essa conta ficaria assim:

>>> print 399999999999999-399999999999998
1

Então, fica a sugestão para os desenvolvedores da calculadora do google: usem python ou alguma biblioteca de precisão arbitrária, para, pelo menos, não confundir os usuários.

Latex, again?

Instalei um plugin de LaTeX no meu wordpress!! Uhu! funciona! Agora posso contar a piada do ricbit:

Um 8 e um e^x andavam tranquilamente por uma rua, quando de repente o 8 se jogou em um beco e se escondeu. O e^x, preocupado, foi atrás dele:

  • O que aconteceu, 8?
  • É que vem vindo ali um operador de derivada. Ele é um desses bullies que vivem me enchendo. Se ele me pega não sobra nada!
  • Pois eu vou atrás dele. Eu sou um e^x e ele não consegue fazer nada comigo.

Então o e^x vai até o operador de derivada e fala com ele:

  • Pare de incomodar o 8! Eu sou um e^x, e você não consegue fazer nada comigo!
  • Muito prazer, e^x. Eu sou o frac{d}{dy}.

(fade out com trilha sonora: http://www.sadtrombone.com/)

Knol, ou uma enxurada de girinadas.

O google lançou o seu complemento/concorrente da wikipédia: knol!

É tudo que um girino pediu a Deus! Nada de fontes, referências, ponto de vista neutro, o escambau aquático! É simplesmente um repositório de conhecimento, QUALQUER UM! Quer lugar melhor pras minhas girinadas? Pois já comecei por lá: escrevi um artiguinho sobre a Lilica Westies, copiei pra lá sem tirar nem por meu tutorial de fractais, e o que eu gastei mais tempo: um artigão, em inglês, introdutório sobre compressão de dados. (Essa foto aí do lado é uma das ilustrações toscas que eu fiz pro artigo 😉 ) Quem animar, dê uma olhada:

Mandelbrot discostas!!!

Ou melhor, nas costas:

Nunca pensei em fazer uma tatuagem, mas essa aí mata a pau! (mas a mulerzinha é meio esquisitinha, ombro demais ou quadril de menos, não consegui descobrir ainda)...

link (thanks ricbit)

Gaveteiro fractal (ou quase)

Foto por: Takeshi Miyakawa Design

Mais uma vez graças ao Boing Boing, uma peça de Design seguindo o estilo fractal: Este gaveteiro projetado pelo estúdio Takeshi Miyakawa Design, de Nova Iorque. Fractal 23, nome dessa peça, é um dos muitos designs com inspirações geométricas desse estúdio.

link (via Boing Boing)