Before I answer your questions - I'll say that looking at the commons-math codebase it is apparent that it's focused on specific functional computation, rather than util-like features. So I agree this probably doesn't fit well there. I honestly did not know commons-numbers existed. I'll check there and then either move this discussion there or commons-lang.
(I'll respond to your questions anyway just in case this ever comes up again or anyone is curious) The use case is reading of text data (e.g. CSV) where significant figures are implied according to the standard rules. Data that is already typed to a standard java Number would have no inherent significant figure tracking and it cannot be reliably determined (for the reasons you mentioned). If the data is represented in that fashion then sigfigs must be provided/applied separately. The significant figures of the input data are inherently "verified" because scientific calculations of this nature are provided by humans (obviously cant account for some forms of human error) and humans will know the precision of their apparatus, and can communicate it using the standard rules of sigfigs - If thats not the case then the user should not be using this api. Because the input data is verified, the output data is also "verified" as long as this logic is correct. I don't believe there is a need for repeating special characters when a number of significant figures is known. In the case of infinite precision, the BigDecimal class already handles that. When significant figures are known then something like 1000/3 can and should be reported as 0.3 (or in scientific notation) because there is only a single significant figure in that calculation. A repeating 3 would imply precision that does not exist. (Admittedly I need to double check this. I know that for pure mathematical values e.g. conversion from feet to inches, the conversion has infinite precision. However as long as the initial measurement has a precision then the output will also necessarily have that same precision). Intermediate calculations can use infinite precision, which could be handled internally via BigDecimal. But final results should be reported with proper sigfig rules applied. You are correct that "1" would not be the same as "1.000" and for clinical / scientific data this is known to be important. "1" implies 1 sigfig, "1.000" implies 4. This is why the data most likely will be represented as text. Determining if the String is a number is simpler in this case I think? Assuming decimal base (and potentially scientific notation) there are a limited number of characters and syntax. isCreateable() attempts to handle different bases as well as type qualifiers whereas this logic would be restricted to decimal base and syntax. (theoretically I suppose you could use a different bases, but scientific calculations are rarely, if ever, carried out in anything other than decimal. Seems natural that they would be out of scope). As for a wrapped class, my initial thought (though I havent worked out the details) would be to extend BigDecimal and use its arithmetic logic. Relevant methods would be overridden to ensure the sigfig subclass is returned. There may be issues with that, I havent fleshed it out. Ultimately the initial goal would be to simply count the number of sigfigs through some text util/parse method. The fact that sigfigs are normally conveyed via textual representation means that many of the issues you might encounter trying to derive them from pure numbers doesn't apply. Hope that answers more questions than it creates! Dan On Wed, Aug 9, 2023 at 8:48 AM Alex Herbert <alex.d.herb...@gmail.com> wrote: > Hi, > > On Wed, 9 Aug 2023 at 12:27, Daniel Watson <dcwatso...@gmail.com> wrote: > > > This feature is necessary when working with scientific/clinical data > which > > was reported with significant figures in mind, and for which calculation > > results must respect the sigfig count. As far as I could tell there is no > > Number implementation which correctly respects this. e.g. > > > > "11000" has 2 significant figures, > > "11000." has 5 > > ".11000" has 5 > > "11000.0" has 6 > > This functionality is not in Commons AFAIK. Is the counting to accept > a String input? > > Q. What is the use case that you would read data in text format and > have to compute the significant figures? Or are you reading data in > numeric format and computing the decimal significant figures of the > base-2 data representation? Note: Differences between base-10 and > base-2 representations can lead to an implementation that satisfies > one use case and not others due to rounding conversions (see > NUMBERS-199 [1]). I would advise against this and only support text > input when referring to decimal significant figures. > > I presume you have input data of unknown precision, are computing > something with it, then outputting a result and wish to use the > minimum significant figures from the input data. If the output > significant figures are critical then this is a case where I would > expect the reported significant figures to be manually verified; thus > automation only partly increases efficiency by providing a first pass. > > Note: I do not think there is an easy way to handle trailing zeros > when not all the zeros are significant [1]. This is in part due to the > different formats used for this such as an overline/underline on the > last significant digit. I do not think we wish to support parsing of > non-ascii characters and multiple options to identify significant > zeros. Thoughts on this? > > Secondly, you are reliant on the text input being correctly formatted. > For example if I include the number 1, it would have to be represented > as e.g. 1.000 to not limit the significant figures of the rest of the > input data. > > Thirdly, if accepting string input then you have the issue of first > identifying if the string is a number. This is non-trivial. For > example there is a function to do it in o.a.c.lang3.math in > NumberUtils.isCreatable. > > Finding a home in commons will elicit different opinions from the > various contributors. The math and numbers projects are more related > to numeric computations. They output results in a canonical format, > typically the JDK toString representation of the number(s). > Conversions to different formats are not in scope, and parsing is > typically from the canonical format using JDK parse methods. There is > a o.a.c.text.numbers package in the text component that currently has > formatting for floating-point numbers to various text representations. > But parsing of Strings is not supported there. And lang has the > NumberUtils. > > As for a class that tracks significant figures through a computation, > that will require some consideration. Do we create the class to wrap > Number and track significant digits of a configurable base. This would > allow BigDecimal with base 10, or int and double with base 2. Since > Number does not specify arithmetic then this has to be captured > somehow. It may be able to use the Numbers implementation of Field [3] > in o.a.c.numbers.field. Or simplify to only using a BigDecimal > wrapper. > > In summary this may be simpler with an ideal use case. For example the > input is text, it must be parable to a BigDecimal and the number of > significant figures is identified using the text input. Support of > significant zeros is limited to the full length of the trailing zeros, > or the first zero if no decimal point is provided. This could be > handled with a parse method that returns both the BigDecimal and the > significant figures. > > Alex > > [1] https://issues.apache.org/jira/browse/NUMBERS-199 > [2] > https://en.wikipedia.org/wiki/Significant_figures#Ways_to_denote_significant_figures_in_an_integer_with_trailing_zeros > [3] http://mathworld.wolfram.com/Field.html > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
