LO calc formulas

[Dante Doménech]

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 (<dante19031999 at gmail.com>)
escribió:

> Ok.
>
> El jue., 10 dic. 2020 10:00, Noel Grandin <noelgrandin at gmail.com>
> escribió:
>
>>
>>
>> On Thu, 10 Dec 2020 at 01:25, Dante Doménech <dante19031999 at 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.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice/attachments/20201211/451ca933/attachment.htm>