Movendo as casas decimais em dobro

Portanto, tenho um conjunto duplo igual a 1234, quero mover uma casa decimal para 12,34

Então, para fazer isso, multiplico 0,1 a 1234 duas vezes, mais ou menos assim

double x = 1234;
for(int i=1;i<=2;i++)
{
  x = x*.1;
}
System.out.println(x);

Isso imprimirá o resultado, "12.340000000000002"

Existe uma maneira, sem simplesmente formatá-lo com duas casas decimais, de ter o armazenamento duplo 12,34 corretamente?

Se você usar doubleou float, deverá usar arredondamento ou poderá ver alguns erros de arredondamento. Se você não pode fazer isso, use BigDecimal.

O problema que você tem é que 0,1 não é uma representação exata e, ao realizar o cálculo duas vezes, você está agravando esse erro.

No entanto, 100 pode ser representado com precisão, então tente:

double x = 1234;
x /= 100;
System.out.println(x);

que imprime:

12.34

Isso funciona porque Double.toString(d)executa um pequeno arredondamento por você, mas não é muito. Se você está se perguntando como seria a aparência sem arredondamentos:

System.out.println(new BigDecimal(0.1));
System.out.println(new BigDecimal(x));

estampas:

0.100000000000000005551115123125782702118158340454101562
12.339999999999999857891452847979962825775146484375

Em suma, o arredondamento é inevitável para respostas sensatas em ponto flutuante, esteja você fazendo isso explicitamente ou não.

Nota: x / 100e x * 0.01não são exatamente os mesmos quando se trata de erros de arredondamento. Isso ocorre porque o erro de arredondamento para a primeira expressão depende dos valores de x, enquanto o 0.01da segunda tem um erro de arredondamento fixo.

for(int i=0;i<200;i++) {
    double d1 = (double) i / 100;
    double d2 = i * 0.01;
    if (d1 != d2)
        System.out.println(d1 + " != "+d2);
}

estampas

0.35 != 0.35000000000000003
0.41 != 0.41000000000000003
0.47 != 0.47000000000000003
0.57 != 0.5700000000000001
0.69 != 0.6900000000000001
0.7 != 0.7000000000000001
0.82 != 0.8200000000000001
0.83 != 0.8300000000000001
0.94 != 0.9400000000000001
0.95 != 0.9500000000000001
1.13 != 1.1300000000000001
1.14 != 1.1400000000000001
1.15 != 1.1500000000000001
1.38 != 1.3800000000000001
1.39 != 1.3900000000000001
1.4 != 1.4000000000000001
1.63 != 1.6300000000000001
1.64 != 1.6400000000000001
1.65 != 1.6500000000000001
1.66 != 1.6600000000000001
1.88 != 1.8800000000000001
1.89 != 1.8900000000000001
1.9 != 1.9000000000000001
1.91 != 1.9100000000000001

Não - se você quiser armazenar valores decimais com precisão, use BigDecimal. doublesimplesmente não pode representar um número exatamente como 0,1, mais do que você pode escrever o valor de um terço exatamente com um número finito de dígitos decimais.

se for apenas formatação, tente printf

double x = 1234;
for(int i=1;i<=2;i++)
{
  x = x*.1;
}
System.out.printf("%.2f",x);

resultado

12.34

Em software financeiro, é comum usar números inteiros por centavos. Na escola, fomos ensinados a usar ponto fixo em vez de flutuar, mas isso geralmente é potências de dois. O armazenamento de moedas de um centavo em números inteiros também pode ser chamado de "ponto fixo".

int i=1234;
printf("%d.%02d\r\n",i/100,i%100);

Em aula, fomos questionados em geral sobre quais números podem ser representados exatamente em uma base.

Para base=p1^n1*p2^n2... você pode representar qualquer N onde N = n * p1 ^ m1 * p2 ^ m2.

Deixe base=14=2^1*7^1... você pode representar 1/7 1/14 1/28 1/49, mas não 1/3

Eu sei sobre software financeiro - converti os relatórios financeiros da Ticketmaster do VAX asm para PASCAL. Eles tinham seu próprio formatln () com códigos para centavos. O motivo da conversão foi que inteiros de 32 bits não eram mais suficientes. +/- 2 bilhões de centavos é $ 20 milhões e isso transbordou para a Copa do Mundo ou as Olimpíadas, esqueci.

Eu jurei segredo. Ah bem. Na academia, se for bom você publica; na indústria, você mantém isso em segredo.

você pode tentar a representação de um número inteiro

int i =1234;
int q = i /100;
int r = i % 100;

System.out.printf("%d.%02d",q, r);

Isso é causado pela maneira como os computadores armazenam números de ponto flutuante. Eles não fazem exatamente isso. Como programador, você deve ler este guia de ponto flutuante para se familiarizar com as tentativas e tribulações de lidar com números de ponto flutuante.

Engraçado que vários posts mencionam o uso de BigDecimal, mas ninguém se preocupa em dar a resposta correta com base em BigDecimal? Porque mesmo com BigDecimal, você ainda pode dar errado, como demonstrado por este código

String numstr = "1234";
System.out.println(new BigDecimal(numstr).movePointLeft(2));
System.out.println(new BigDecimal(numstr).multiply(new BigDecimal(0.01)));
System.out.println(new BigDecimal(numstr).multiply(new BigDecimal("0.01")));

Dá esta saída

12.34
12.34000000000000025687785232264559454051777720451354980468750
12.34

O construtor BigDecimal menciona especificamente que é melhor usar o construtor String do que um construtor numérico. A precisão máxima também é influenciada pelo MathContext opcional.

De acordo com o Javadoc BigDecimal , é possível criar um BigDecimal que seja exatamente igual a 0,1, desde que você use o construtor String.

Sim existe. Com cada operação dupla, você pode perder a precisão, mas a quantidade de precisão difere para cada operação e pode ser minimizada escolhendo a sequência correta de operações. Por exemplo, ao multiplicar um conjunto de números, é melhor classificar o conjunto pelo expoente antes de multiplicar.

Qualquer livro decente sobre análise de números descreve isso. Por exemplo: http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html

E para responder à sua pergunta:

Use dividir em vez de multiplicar, dessa forma você obterá o resultado correto.

double x = 1234;
for(int i=1;i<=2;i++)
{
  x =  x / 10.0;
}
System.out.println(x);

Não, como os tipos de ponto flutuante Java (na verdade, todos os tipos de ponto flutuante) são uma compensação entre tamanho e precisão. Embora sejam muito úteis para muitas tarefas, se você precisa de precisão arbitrária, deve usar BigDecimal.