After some thought, this wrapper class might be better named something like
BigMeasurement (or just Measurement?). Significant figures and precision
are very closely tied to measurements, since the act of measuring is really
what causes the uncertainty to begin with.
I think a static method to count sigfigs is worth adding to commons-lang
math utils, so ill propose it there. As for a wrapper class, Im not so
sure. Measurement calculation seems closer to something like
commons-numbers, but if its not quite close enough to fit then i'll just
retain it in my personal commons.
Thanks for the discussion!
On Wed, Aug 9, 2023 at 3:00 PM Daniel Watson <dcwatso...@gmail.com> wrote:
> 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
>>
>>
