I've been digging into calc code. And it makes me wonder about a few things. First, in here: core <https://opengrok.libreoffice.org/xref/core/>/include <https://opengrok.libreoffice.org/xref/core/include/>/rtl <https://opengrok.libreoffice.org/xref/core/include/rtl/>/math.hxx <https://opengrok.libreoffice.org/xref/core/include/rtl/math.hxx> We have our own isnan, isinf, isfinite, ... and some of them with quite strange code. Why is the default c++ standard library isn't good enough? The same goes for floor / ceil / round ... Thank you for your time.
El jue, 10 dic 2020 a las 14:38, Dante Doménech (<dante19031...@gmail.com>) escribió: > Ok. > > El jue., 10 dic. 2020 10:00, Noel Grandin <noelgran...@gmail.com> > escribió: > >> >> >> On Thu, 10 Dec 2020 at 01:25, Dante Doménech <dante19031...@gmail.com> >> wrote: >> >>> I-ll implement a second order kahan algorithm. Third order would be >>> overkill ( I don't think anyone is gonna use it for high precision >>> calculus ). >>> But it's not only sum and average, variance (stats) and any other >>> formula with sums is affected. That's why I need time to track it. >>> And by the way, what about using long double for intermediate steps, to >>> improve precision. For what I know glibc or whatever uses gcc on fedora >>> uses it, >>> >> >> >> Note that calc is, in general, quite performance sensitive in that people >> care about how long it takes to calculate large spreadsheets (and some of >> them can get very large indeed). >> >> So 128-bit floating point would probably be tricky since CPU largely >> don't have hardware support for direction operations on that. >> >
_______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
