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
