On Tue, 18 Jul 2023 at 09:43, Gilles Sadowski <gillese...@gmail.com> wrote: > > Hello. > > Le mar. 18 juil. 2023 à 02:48, Dimitrios Efthymiou > <efthymiou.dimitri...@gmail.com> a écrit : > > > > Thanks Gilles. I checked NUMBERS-193 and i have an implementation of DD and > > i will put it in *.ext package (TBD) along with some tests. Do i have to > > look at Dfd.java or something, because these dfd classes in math legacy > > core have lots of hard-coded decimals in there. > > Yes, we need to sort out what to with with the "Dfp" classes: I don't > know how useful they will be once the DD implementation is available. > We'll perhaps need benchmarks to assess speed vs precision among > all extended precision implementations: > * DD in [Numbers], > * Dfp in [Math] > * BigDecimal in the JDK > > If "Dfp" is somehow (TBD) useful, it should be moved to a module of > its own, perhaps in [Numbers].
Note: Dfp is not in the same category as a double-double number as it is an "unlimited" precision number. It has a configurable decimal precision and a larger exponent range than a double. It also has support for various elementary functions (exp, exp1p, log, log1p, sin, cos, etc). As such it is very valuable to fill a void where BigDecimal cannot be used since that only supports pow and, from JDK 9+, sqrt. I expect the speed would be comparable to BigDecimal and so a JMH test would be useful. Moving it out of math to a new module in numbers would be a chance to revisit the code. But it is a large and complex class. I would not change its implementation without a very thorough set of tests against other comparable unlimited precision number implementations in other libraries (Python mpmath; Maxima; Matlab vpa; etc). Alex --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
