Summary: | enhancement: CALCULATION: implement a function 'rawsum', working without prettyfying as rawsubtract does | ||
---|---|---|---|
Product: | LibreOffice | Reporter: | b. <newbie-02> |
Component: | Calc | Assignee: | Not Assigned <libreoffice-bugs> |
Status: | UNCONFIRMED --- | ||
Severity: | enhancement | CC: | 79045_79045, erack, mikekaganski |
Priority: | medium | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Crash report or crash signature: | Regression By: | ||
Bug Depends on: | |||
Bug Blocks: | 108827 |
Description
b.
2021-08-15 18:34:55 UTC
Eike, Mike, what do you think about this suggestion? I'm unbiased. What comes next, RAWEQUAL()? Btw, > which is violating IEEE 16 digit accuracy is not true. There is no such thing. There's a theoretical *average* precision of 15.95 decimal digits (=LOG10(2^53)) but that doesn't hold true either. Read https://www.exploringbinary.com/decimal-precision-of-binary-floating-point-numbers/ Summarizes best with "The three reasonable answers are 15 digits, 15-16 digits, and slightly less than 16 digits on average. The safe answer is 15 digits." > RAWEQUAL()? _is_ an idea, > 15 / 16 digit accuracy? in this range! the precision is some 16+ digits, 2.000000000000000, 2.000000000000001, 2.000000000000002, 2.000000000000003, 2.000000000000004, 2.000000000000005, 2.000000000000006, 2.000000000000007, 2.000000000000008, 2.000000000000009, and 2.000000000000010, are representable, and additional we have 2.0000000000000013, 2.0000000000000018, 2.0000000000000027, 2.0000000000000036, 2.0000000000000044, 2.0000000000000053, 2.0000000000000058, 2.0000000000000067, 2.0000000000000075, 2.0000000000000084, 2.0000000000000093, 2.0000000000000098, |