| Summary: | calc: calculate: trap in rawsubtract, wrong calculation sequence, documentation imprecise | ||
|---|---|---|---|
| Product: | LibreOffice | Reporter: | b. <newbie-02> |
| Component: | Calc | Assignee: | Not Assigned <libreoffice-bugs> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | 6.1.6.3 release | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Crash report or crash signature: | Regression By: | ||
|
Description
b.
2021-04-19 03:51:59 UTC
Absolutely *no* reason to introduce any specific order in this case. No matter what sequence will be used, the outcome will be equally confusing to most users, and those who know enough of FP math, will not be confused. *** This bug has been marked as a duplicate of bug 137679 *** @Mike Kaganski: sorry for objecting: 1. users who know enough about fp-math, know that the calculating sequence matters, and do meaningful (small to big?) operand ordering acc. the sequence minuhend - subtrahend1 - subtrahend2 - subtrahend3 ... will be trapped, will be astonished that it doesn't work as expected and documented, and turn away frustrated with the idea 'fp-math is imprecise' ... we already have too much of these people, missing for making a good program, and it's unjustified, fp-math and IEEE 754 is! precise (to some degree), calc is messing it up in some respects, this case is clearly calc bullshitting and you defending it ... and it's never ever a dupe of a kahan summation enhancement request, it might be covered with kahan, might as well have / cause problems, see comment https://bugs.documentfoundation.org/show_bug.cgi?id=137679#c14, but in it's source it's different ... suggest unduping ... else ... file one big bug 'fp-math is imprecise', mark it as 'wontfix' and any calculation bugs as dupes and you are done ... ;-) |