Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <blockquote> <p>If this is not the right answer, what CAN we use for exact division in financial calculation? (I mean, I don't have a finance major, but they still use division, right???).</p> </blockquote> <p>Then I was in primary school<sup>1</sup>, they taught me that when you divide by 1 by 3 you get a 0.33333... i.e. a <em>recurring</em> decimal. Division of numbers represented in decimal form is NOT exact. In fact for any fixed <em>base</em> there will be fractions (the result of dividing one integer by another) that cannot be represented <em>exactly</em> as a finite precision floating point number in that base. (The number will have a recurring part ...)</p> <p>When you do financial calculations involving division, you <em>have</em> to consider the what to do with a recurring fraction. You can round it up, or down, or to the nearest whole number, or something else, but basically you <em>cannot</em> just forget about the issue.</p> <p>The BigDecimal javadoc says this:</p> <blockquote> <p>The BigDecimal class gives its user complete control over rounding behavior. If no rounding mode is specified and the exact result cannot be represented, an exception is thrown; otherwise, calculations can be carried out to a chosen precision and rounding mode by supplying an appropriate MathContext object to the operation. </p> </blockquote> <p>In other words, it is <em>your responsibility</em> to tell BigDecimal what to do about rounding.</p> <p><strong>EDIT</strong> - in response to these followups from the OP.</p> <blockquote> <p>How does BigDecimal detect infinite recurring decimal? </p> </blockquote> <p>It does not explicitly detect the recurring decimal. It simply detects that the result of some operation cannot be represented exactly using the specified precision; e.g. too many digits are required after the decimal point for an exact representation.</p> <blockquote> <p>It must keep track of and detect a cycle in the dividend. It COULD HAVE chosen to handle this another way, by marking where the recurring portion is, etc.</p> </blockquote> <p>I suppose that <code>BigDecimal</code> could have been specified to represent a recurring decimal exactly; i.e. as a <code>BigRational</code> class. However, this would make the implementation more complicated and more expensive to use<sup>2</sup>. And since most people expect numbers to be displayed in decimal, and the problem of recurring decimal recurs at that point.</p> <p>The bottom line is that this extra complexity and runtime cost would be inappropriate for typical use-cases for <code>BigDecimal</code>. This includes financial calculations, where accounting conventions do not allow you to use recurring decimals.</p> <hr> <p><sup>1 - It was an excellent primary school ...</sup></p> <p><sup>2 - Either you try to remove common factors of the divisor and dividend (computationally expensive), or allow them to grow without bounds (expensive in space usage ... and computationally for later operations).</sup></p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload