Transformando 0.33333333333 em 0.3 / 0.166666666666666 em 0,16

se nao tiver problemas em arredondar os valores, assim faz:

DecimalFormat df = new DecimalFormat("##.##;(00.00)");

System.out.println(df.format(0.333333333));

System.out.println(df.format(0.166666666666));

Pode usar o Math.round e o Math.floor, dependendo da sua “criatividade”:

double a = Math.round((1.0/3)*10)/10.0;
double b = Math.floor((1.0/3)*10)/10.0;

Ou, como é dízima, pode fazer assim:

double a = 1.0/3; // 0.33333
  double b = a - a/10; // aqui você também pode fazer uma lógica para tirar a parte que não é dízima.

Sinceramente, prefiro a primeira opção.

Muito mais simples usar o BigDecimal.

BigDecimal decimal = new BigDecimal(0.3333d);
		decimal.setScale(2, RoundingMode.HALF_UP); //Além de permitir arredondamento, lhe permite escolher se será para cima ou para baixo

para calculos com casas decimais, eu sempre uso bigdecimal, principalmente se for algo que mecha com o lado financeiro

double valor = Double.paserDouble(String.format("%.2f", 0.333333333)); double valor2 = Double.parseDouble(String.format("%.2f", 0.166666666666));

Giulliano:

Muito mais simples usar o BigDecimal.

BigDecimal decimal = new BigDecimal(0.3333d);
		decimal.setScale(2, RoundingMode.HALF_UP); //Além de permitir arredondamento, lhe permite escolher se será para cima ou para baixo

jaboot:

Giulliano:

Muito mais simples usar o BigDecimal.

BigDecimal decimal = new BigDecimal(0.3333d);
		decimal.setScale(2, RoundingMode.HALF_UP); //Além de permitir arredondamento, lhe permite escolher se será para cima ou para baixo

++ O único problema de usar o BigDecimal é o custo. Mas como as vezes o que mais importa no sistema são os valores ($$$), eu acho que vale a pena.

jaboot ou wellington.nogueira

vocês saberiam responder o quanto mais lento é o BigDecimal para o Double. Por que se estamos falando de nanosegundos ou milisegundos, podemos descartar essa lentidão.

Faz um loop-teste com os seus cálculos e vê a diferença.

Eu sinceramente não sei quantos milisegundos vai dar de diferença.

jaboot:

Faz um loop-teste com os seus cálculos e vê a diferença.

Eu sinceramente não sei quantos milisegundos vai dar de diferença.

legal pessoal…a ideia era só deixar bem claro que não vale a pena descartar bigdecimal, achando que ele prejudicaria a performance (salvo casos extermos).

aproveitando sugiro a todos darem uma lida no post da caelum http://blog.caelum.com.br/arredondamento-no-java-do-double-ao-bigdecimal/

[]'s a todos.

Giulliano:

Muito mais simples usar o BigDecimal.

BigDecimal decimal = new BigDecimal(0.3333d);
		decimal.setScale(2, RoundingMode.HALF_UP); //Além de permitir arredondamento, lhe permite escolher se será para cima ou para baixo

Prefira que as operações matemáticas (soma, subtração, multiplicação e divisão) sejam realizadas pelo BigDecimal (entretanto, esse cálculo fica mais lento).

@Giulliano, a questão é que vc vai gerar overhead por passar a trabalhar com o BigDecimal. Em geral não deve influenciar mas tudo vai depender do volume de cálculos a serem realizados.

Entretanto, é muito comum utilizar valores flutuantes para tratar valores monetários e, menos comum, para valores de engenharia. E em ambos casos, a precisão tem maior importância/significância que a performance.

Se quiser saber a diferença, pode fazer como sugeriu o @jaboot mas faça o monitoramento acompanhado de um Profiler (Ex.: JVisualVM).