https://bugs.documentfoundation.org/show_bug.cgi?id=87386
k...@cox.net changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|NOTABUG |---
--- Comment #10 from k...@cox.net ---
Some people need to learn that computers and software are supposed to work for
people. People do not work for computers. Telling someone they have to do what
the computer wants doesn't resolve the problem (in this case, random wrong
answers). So, "not a proper use of general numbers", "will never work reliably"
and "Floating point numbers just don't work that way" don't change the fact
that this is a bug.
The whole point of GUIs is "what you see is what you get". If someone sees
"0.09", it is reasonable for them to expect it to work in calculations as 0.09,
and it normally will. Where it won't is with any function that truncates digits
without regard to their significance, so for those types of functions, the
software must account for the fact that computers must work with more digits
than they show, so they can display the correct answer.
This is not a problem with number types. It is a problem with algorithms used
for functions. As has been pointed out in the thread of a related bug with the
MOD() function, random wrong answers due to inadequate or improper handling of
significant digits is not acceptable to anyone in a job where life or property
could be harmed or lost by such an error. That means engineers, logisticians,
doctors and accountants should not use the MOD() or DATE() functions in
LibreOffice.
The fact that this discussion is ongoing tells me spreadsheet functions haven't
been standardized, and that's too bad. I'm stuck with MS Excel for the
foreseeable future, since the open source community apparently doesn't
understand user requirements for spreadsheets. I got involved in bug reporting,
thinking the community might want to know what users need. Now I'm not sure
they do.
Someone who wants to get away from Windows won't find a spreadsheet for Linux
that can be depended on for all the functions I use. But LibreOffice comes with
those functions, and most people don't know they can give wrong answers. You
could bury a warning with descriptions of the MOD() and DATE() functions saying
they shouldn't be used for important work, but what engineer or accountant
needs to read the descriptions of MOD() and DATE(). If the function doesn't
work reliably, it shouldn't be implemented.
DATE() and MOD() worked as they should for the more than 20 years I've used
them in Excel, so when someone tells me one "will never work reliably", it
sounds like they think the current algorithm is the only one possible. I can
think of many ways to work around the problem, but why would I unless I know
the functions don't work properly? Most LO Calc users don't know, and if they
did, I suspect they would not be happy if they use the DATE() function.
If I were programming a DATE() function that expected only integers as input
for YEAR, MONTH, or DAY, I would make very sure that every passed value was
appropriately rounded BEFORE being used in the function. (However, I probably
wouldn't design the DATE() function to expect only integers, because dates are
stored as floating point days that can include the information returned by
TODAY() or NOW(), so the DATE() function should allow addition of decimal days
to the value returned by NOW() or any other date/time.)
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
