Pegadinha

ai blz …

letra a) 0.009999999999990905

falou…

Seu compilador é muito inteligente, acertou o valor da subtração, porém você errou a letra, esse valor era esperado?

Faça a mesma subtração na calculadora pra ver o resultado… :roll:

[color=“red”]Alguém sabe porque o resultado é 0.009999999999990905
quando na verdade 688.72 - 688.71 é 0,01?

Existe alguma formatação pra esse valor chegar aproximado a 0,01?
[/color]

usa assim pra resposta ser a letra B

BigDecimal var1 = new BigDecimal("688.72");
BigDecimal var2 = new BigDecimal("688.71");
System.out.println(var1.subtract(var2));

“pregospan”:

usa assim pra resposta ser a letra B

BigDecimal var1 = new BigDecimal("688.72"); BigDecimal var2 = new BigDecimal("688.71"); System.out.println(var1.subtract(var2));

Opa valeu, assim funcionou perfeito, mas será que não existe outra forma de formatação? Porque desta forma irei trabalhar com Objetos e não com tipos primitivos, com isso irá tornar o processamento mais lento. É só questão de perfomance mesmo, se você souber dizer… mesmo assim valeu!

???

Mas é tão mais lento? O quanto que custa essa lentidão? 8O

Eu sei que quando utilizamos tipos primitivos (eu não uso mais…) com ponto flutuante, o resultado de 0.1 + 0.9 poderá dar 0.9999999

???

Mas é tão mais lento? O quanto que custa essa lentidão? 8O

Uma geração de relatório, por exemplo…

Queria saber pq o double não suporta (não dá o valor esperado) operações do tipo:

(71.77 + 0.02) - 71.79

O resultado não dá 0 e sim um número em ponto flutuante.

A explicação é que esses números são dízimas.
Acho que você pode usar a classe Formatter pra obter o resultado esperado.

As classes de ponto flutuante são apra matemática de ponto flutuante, não matemática exata. O resultado não está errado, pelo contrário Java consegue resultados bem exatos, mas o problema é que você está esperando matemática exata e doubles e floats não fazem isso.

Duas soluções: BigDecimal ou outra classe representando números.

Acredite: você não terá um desempenho tão diferente assim.

“pcalcado”:

As classes de ponto flutuante são apra matemática de ponto flutuante, não matemática exata. O resultado não está errado, pelo contrário Java consegue resultados bem exatos, mas o problema é que você está esperando matemática exata e doubles e floats não fazem isso.

Duas soluções: BigDecimal ou outra classe representando números.

Acredite: você não terá um desempenho tão diferente assim.

Vindo de você vou repensar no assunto, obrigado Phillip!

Ta… muito interessante, mas ainda nao entendi o pq dessa “falha” qndo trabalha-se com pontos flutuantes. Vc poderia me explicar shoes?

Vlw,
Dark.

Eu não sou engenheiro nem físico ou derivados logo meu entendimento sobre o porque de álgebra não-exata é superficial. O que eu sei é que a implementação segue o padrão IEEE.

De qualquer maneira o que eu falei é melhor explicado em outros lugares como Effective Java, de Joshua Bloch. Procure no Google e você vai ter diversas fotnes também.

Uma ótima explicação foid ada pelo grande Luca no GUJ:
http://www.guj.com.br/posts/list/10228.java

Atualmente eu tenho definido uma classe “Moeda” que guarda os valores dos centavos num long.

“pcalcado”:

Eu não sou engenheiro nem físico ou derivados logo meu entendimento sobre o porque de álgebra não-exata é superficial. O que eu sei é que a implementação segue o padrão IEEE.

De qualquer maneira o que eu falei é melhor explicado em outros lugares como Effective Java, de Joshua Bloch. Procure no Google e você vai ter diversas fotnes também.

Uma ótima explicação foid ada pelo grande Luca no GUJ:
http://www.guj.com.br/posts/list/10228.java

Atualmente eu tenho definido uma classe “Moeda” que guarda os valores dos centavos num long.

Tem como disponibilizá-la? :roll:

Quando se converte um número fracionário exato da base 10 para a base 2, muitas vezes ele se torna uma dízima.
Ex: 0,2 = 0,00110011…

Não tem como representar de forma exata um número desses.