Bigdecimalhttps://polgrabia.me/tags/bigdecimal/2025-03-12T00:20:58+02:00Tomasz PółgrabiaHugoBigDecimal - why do we need it?https://polgrabia.me/posts/20250312-bigdecimal-why-do-we-need/2025-03-12T00:20:58+02:002025-03-12T00:20:58+02:00<h2 id="why-do-we-need-it">Why do we need it?</h2>
<p>This question is the pretty standard one in algorithmic interview questions. So, why do we need it? I think it’s fair to ask.
The main reason behind this is knowing how floating point numbers are being stored. Usually, you don’t need it to use
this knowledge otherwise to know “solution” but it’s good to know.</p>
<p>The main reason is the precision or rather, the lack of it. In environments where we need to have big numbers very precise like
face values and when it’s multiplied by exchange ratios, the potential difference can be very signifcant. Therefore potential
financial risk can be signifcant, too.</p>
<p>The standard double (or even more float) is stored with 8 bytes, the standard float consumes 4 bytes. However, it doesn’t
explain yet the reason why. Let’s take look it.</p>
<h2 id="root-causes">Root causes</h2>
<p><a href="https://en.wikipedia.org/wiki/Double-precision_floating-point_format">Floating point precision</a></p>
<p>Let’s take a look how typical double looks like.</p>
<ul>
<li>Sign bit (most significant, the left one)</li>
<li>Exponent (11 bits)</li>
<li>Significand precision (mantissa) (53 bits, 52 stored).</li>
</ul>
<p>So, we see that the formula for our double number is as it follows:</p>
<div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;"><code class="language-text" data-lang="text"><span style="display:flex;"><span style="white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#7f7f7f">1</span><span>sign * mantissa * exponent
</span></span><span style="display:flex;"><span style="white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#7f7f7f">2</span><span>{1,1} * <1,2) * (2**exp)
</span></span></code></pre></div><p>where both mantissa and exponent are stored binary wise.</p>
<p>Knowing this, we see the formula for granularity is (2 ** (-11)) * (2 ** exponent) where the first part comes from mantissa precision
(smallest difference in mantissa). When it’s applied to exponent (in binary representation), we see the granularity will be decreasing
for the smaller numbers and increasing for the bigger numbers.</p>
<p>For the big numbers like millions, especially when it’s a result of more complex formulas containing more factors and especially division
(it’s advised to divide numbers as late as it’s possible), the potential error caused by granularity and representation errors can
be really signifcant.</p>
<h2 id="how-bigdecimal-are-different">How BigDecimal are different?</h2>
<p>BigDecimals don’t have the same limits as stndard floating point types. They are being stored ‘digit-wise’, digit by digit and they potentially
have unlimited number of digits allowed to be stored in BigDecimal (mantissa part) stored as BigIntiger under the hood
(decimal wise… in the simplest implementation. Real implementation dealing with “compact” and “non-compact” case you can check
in the github source code of openjdk).</p>
<p>However, they still cannot hold rational numbers like ( 2 / 3 ) and thus they cannot have “infinite” number representation of rational number.
Therefore, you need to be very careful when you divide and preferably perform it at the very end of computations.</p>
<p>Be careful with representing dividing like 1 / 3 * 3 != 1 in computer world… (1 / 3 cannot be stored precisely in binary stored mantissa)</p>
<h2 id="conclusion">Conclusion</h2>
<p>The point is - just use BigDecimal when you suspect that you may need big numbers with good precision.</p>