I believe the convention is to take the *least* precise term and apply that
precision (here "precision" != "sigfigs" - Ive been using both terms to
mean sigfigs, but for these purposes precision is actually defined as how
small a fraction the measurement is able to convey - e.g 0.01 is more
precise than 10000.1, despite the latter having more sigfigs).
The results should be...
12345 + 10.0 = 12355
12345 + 10 = 12355
12345 + 1 = 12346
12345 + 1.0 = 12346
12345 + 1.0 = 12346
None of these will have decimal places because the left term was not
precise enough to have them. When adding/subtracting you can end up with
more significant figures in your result than you had in one of your terms,
you just can end up with a more "precise" result than either of your
terms.e.g.
999.0 + 9.41 = 1008.4
4 sigfigs + 3 sigfigs = 5 sigfigs - It's perfectly fine that we ended up
with more here, as long as we didnt increase the "precision".
So in this case I think the correct logic is to add the two terms together
in the normal way, reduce the precision to that of the limiting term, and
then recalculate the number of significant figures on the result.
I believe that, conveniently, the BigDecimal class already tracks this as
scale(). So the information is available to determine the new precision. It
would just be a matter of retaining it within the wrapper class and
applying it when producing the final output string. I'd need to play around
with a few more examples, but I think that's the logic at a high level.
Dan
On Wed, Aug 9, 2023 at 2:08 PM Alex Herbert <alex.d.herb...@gmail.com>
wrote:
> On Wed, 9 Aug 2023 at 17:13, Daniel Watson <dcwatso...@gmail.com> wrote:
>
> > BigSigFig result = new BigSigFig("1.1").multiply(new BigSigFig("2"))
>
> Multiply is easy as you take the minimum significant figures. What
> about addition?
>
> 12345 + 0.0001
>
> Here the significant figures should remain at 5.
>
> And for this:
>
> 12345 + 10.0
> 12345 + 10
> 12345 + 1
> 12345 + 1.0
> 12345 + 1.00
>
> You have to track the overlap of significant digits somehow.
>
> Alex
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
