Ah I see what you were asking. Yes it is up to the human entering data to understand that 10000 has exactly one sigfig according to standard convention. If you need it to have more then you must write it in full scientific notation. Obviously If a specific precision is required due to some flaw in the dataset then the user could manually override the detected sigfig count. But the assumption of the parsing logic is that the input abides by the standard convention, which is well defined. I don't see it as being much different than any other Number class expecting the input to abide by a specific format. Conventions for SigFig counting are well defined. It just so happens that most people don't often need them (but the same could be said for o.a.c.numbers.Complex).
As far as exact calculations, if the user did: BigSigFig result = new BigSigFig("1.1").multiply(new BigDecimal("2.54")) I would expect the BigSigFig class should understand that BigDecimal has no sigfig limit, and would retain it's current minimum of 2. It would only apply a new minimum in the case of operating against another BigSigFig... BigSigFig result = new BigSigFig("1.1").multiply(new BigSigFig("2")) The result of that should be a BigSigFig with an internal value of exactly 2.2 but would output as "2" to respect the new sigfig count. I think something like that should be possible. In the end this is more of a parsing / formatting exercise. The wrinkle is the tracking aspect, where we need to dynamically reduce the sigfigs based on other operations. That's where a wrapper class I think comes in handy. Dan On Wed, Aug 9, 2023 at 11:23 AM Alex Herbert <alex.d.herb...@gmail.com> wrote: > On Wed, 9 Aug 2023 at 15:43, Daniel Watson <dcwatso...@gmail.com> wrote: > > > > Hope that answers more questions than it creates! > > It does not address the issue of the last significant zero, e.g: > > 10000 (4 sf) > 10000 (3 sf) > 10000 (2 sf) > > One way to solve this with standard parsing would be to use scientific > notation: > > 1.000e4 > 1.00e4 > 1.0e4 > > Note that for the example of inch to cm conversions the value 2.54 > cm/inch is exact. This leads to the issue that there should be a way > to exclude some input from limiting the detection of the lowest > significant figure (i.e. mark numbers as exact). This puts some > responsibility on the provider of the data to follow a format; and > some on the parser to know what fields to analyse. > > Alex > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >