2010-07-21 8 views
5
new BigDecimal("37146555.53880000").divide(new BigDecimal("1000000")).scale() 

Cela renvoie 10. Mais selon l'API, la méthode divide:Scale() de la méthode de division dans le BigDecimal

Renvoie un BigDecimal dont la valeur est (ce/diviseur), et dont l'échelle est préférée (this.scale() - divisor.scale());

Donc dans ce cas, 37146555.53880000's échelle est 8, et à l'échelle de 1000000 est 0. Donc, le résultat devrait avoir une échelle de 8, pas 10.

Qu'est-ce qui me manque ici?

Merci

Répondre

2

Le résultat actuel est 37,1465555388 dont l'échelle doit être 10 pour être exacte. Ce que le JavaDoc dit est que l'échelle préférée est la différence signifiant que si le résultat n'a pas réellement besoin d'être 10, alors il essaierait de le faire 8. Par exemple si vous auriez divisé par 2, dont échelle est également 0, le résultat aurait été 18573277.76940000 (échelle 8).

EDIT: petite adition - vous pouvez forcer la division à une certaine échelle en utilisant les méthodes de diviser surchargées:

  • divide(BigDecimal, RoundingMode) qui donnera une BigDecimal avec échelle de this et valeur arrondie selon la méthode d'arrondi spécifié si le résultat nécessite réellement plus de décimales pour être exact.

  • divide(BigDecimal, scale, RoundingMode) qui donnera un BigDecimal avec l'échelle spécifiée, et la valeur arrondie par la méthode spécifiée si nécessaire.

Cela peut être utile si votre division par un numéro que vous connaissez peut provoquer décimaux répéter, comme 3 (1/3 = 0,333333 ...) car, si cela arrive, la fracture simple va lancer une exception. En le liant à un nombre maximum de décimales, vous éviterez l'exception mais rendra vos calculs moins précis.

1

Ces échelles sont celles utilisées par les méthodes qui renvoient l'arithmétique des résultats exacts; sauf qu'une division exacte peut avoir à utiliser une plus grande échelle puisque le résultat exact peut avoir plus de chiffres. Par exemple, 1/32 est 0,03125.