[code]public class Main {
public static void main(String[] args) {
double x = Double.parseDouble("6.84");
double y = Double.parseDouble("10.50000000");
System.out.println(x * y * 100d);
System.exit(0);
}
}[/code]
Resultado deve ser 7182.0, entretanto imprime 7181.999999999999 8O
Se alguém conseguir imprimir diretamente o resultado da multiplicação destes 3 valores, por favor poste a solução!
==================
java version “1.5.0_02”
Java™ 2 Runtime Environment, Standard Edition (build 1.5.0_02-b09)
Java HotSpot™ Client VM (build 1.5.0_02-b09, mixed mode, sharing)
ola, minha resposta vai em tom de pergunta:
nao eh preciso colocar 0x pra usar hexadeciamal?
System.out.println(x * y * 0x100d);
em que casos é necessario?
fiz a conta x * y numa calculadora e o resultado foi 71.82 … talvez seja nessa segunda multiplicacao o problema.
flw
Eu acho que a única solução é usar o arredondamento
Atenciosamente,
Bento Monteiro
SCJP
[quote=“javaAdicted”]
nao eh preciso colocar 0x pra usar hexadeciamal?
System.out.println(x * y * 0x100d);
[/quote]
100 em hexa é 0x64, e mesmo assim continuou a dar o erro de arredondamento
exatamente, maldita base decimal!!!
Pela centionosésima vez:
NÃO USE TIPOS PRIMITIVOS PARA OPERAÇÕES EXATAS!
BigDecimal é o que você procura.
[quote=“pcalcado”]Pela centionosésima vez:
NÃO USE TIPOS PRIMITIVOS PARA OPERAÇÕES EXATAS!
BigDecimal é o que você procura.[/quote]
tens alguma referência (da Sun de preferência) para esta recomendação?
pessoalmente, acho q o overhead na utilização de objetos para tais operações é um preço muito alto a se pagar!
Google: BigDecimal + rounding + double
[quote=“viecili”]
pessoalmente, acho q o overhead na utilização de objetos para tais operações é um preço muito alto a se pagar![/quote]
E você tem essa opnião baseada exatamente em que?
Shoes
viecili, o preço será mais alto qnd começar a fazer cálculos com doubles onde a precisão é muito importante como em dinheiro, e ver q é gerado resultados erroneos conforme vai executando operações em cima desses doubles… :roll:
não é o melhor benchmark, mas acho q serve:
[code]import java.math.BigDecimal;
public class Objeto {
public static void main(String[] argv) {
long inicio = System.currentTimeMillis();
BigDecimal bx = new BigDecimal(6.84);
BigDecimal by = new BigDecimal(10.5);
for (int i = 0; i < 500000; i++) {
BigDecimal sub = by.subtract(bx);
BigDecimal add = by.add(bx);
BigDecimal div = by.divide(bx,BigDecimal.ROUND_FLOOR);
BigDecimal mul = by.multiply(bx);
}
System.out.println((System.currentTimeMillis() - inicio)+" ms");
}
}[/code]
e
[code]public class Primitivo {
public static void main(String[] argv) {
long inicio = System.currentTimeMillis();
double ix = 6.84;
double iy = 10.5;
for (int i = 0; i < 500000; i++) {
double sub = iy - ix;
double add = iy + ix;
double div = Math.ceil(iy / ix);
double mul = iy * ix;
}
System.out.println((System.currentTimeMillis() - inicio)+" ms");
}
}[/code]
[code]C:\DOCUME~1\viecili\Desktop\arred>java Objeto
7921 ms
C:\DOCUME~1\viecili\Desktop\arred>java Primitivo
78 ms[/code]
custava à Sun fazer com que o custo da precisão não fosse TÃO caro!!
Você ainda não ganhou precisão nenhuma, leia mais sobre BigDecimal.
Ainda assim, seu benchmark não prova nada. É óbvio que objetos serão mais lentos que primitivos, mas eles também trazem vantagens. Para programar sem objetos, use C. Se você precisa de cálculos na velocidade da luz, esqueça Java.
Quanto à custar ou não, quem realmente precisa de cálculos bizarros usa double e demais porque geralmente essas pessoas trabalham com matemática não exata, mas de ponto flutuante. Para aqueles que trabalham com moeda e outras grandezas exatas, nunca vi reclamações.
Novamente: leia mais sobre BigDecimal e matemática em java.
Shoes
era nesse ponto q eu queria chegar, custava ter um mecanismo um pouco melhor pra tratar tipos primitivos?
de vez em quando me espanta o rumo q a tecnologia toma!
BigDecimal foi uma das alternativas sugeridas por mim por aki, mas ‘bateu na trave’ por causa deste desempenho terrível, mas se não há outra forma de garantir precisão, acho q vai ter q ser este o jeito…
obrigado pelas contribuições pessoal
[quote=“viecili”]era nesse ponto q eu queria chegar, custava ter um mecanismo um pouco melhor pra tratar tipos primitivos?
[/quote]
Tem, remover eles e colaborar para uma linguagem mais OO.
Shoes