Are there any existing projects that have this functionality now? E.g. if there's some physics project, some ML project, and some DNA project that have all had to reinvent this particular wheel, that's both good evidence that we need it and something to inform us of what a useful API might look like here.
If, on the other hand, this isn't commonly useful, then we might not want to carry the ongoing maintenance burden for these methods. On Thu, Aug 10, 2023 at 2:55 PM Daniel Watson <dcwatso...@gmail.com> wrote: > > I brought this up in commons-math and it was determined that that probably > wasn't a good place for it, as that lib focuses on computational functions. > It was also mentioned that commons-numbers was not a great place for the > static util method either. > > Essentially the need for this relates to scientific measurements. > Measurements are often reported with implied precision and uncertainty > (e.g. 0.0015 has 2 significant figures, 1.10 has 3, etc). Currently there > are no Number classes that retain or respect this information. There are > widely accepted conventions for how to retain and adjust both precision and > uncertainty during mathematical operations. But the first step is simply > knowing what those two values are. I propose a util method (already > written) in NumberUtils that can do this. The conventions are widely > documented but would be spelled out very specifically in the javadoc. > Although NumberUtils mainly focuses on pure math transformation, it does > also include some parsing, so this doesn't seem to be *completely* out of > scope. > > Is NumberUtils a possible home for this? > > On a separate, but related note, I honestly think this sort of math > actually deserves a full blown java Number implementation (similar to > BigFraction and Complex classes in commons- numbers). Possibly called > BigMeasurement? Which can interact with other Number implementations as > well as other BigMeasurements and retain/report the correct uncertainty and > precision throughout the computation. I haven't ironed that out - but a > necessary intermediate step is just being able to get the sigfig count. > > Dan -- Elliotte Rusty Harold elh...@ibiblio.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
