https://bugs.documentfoundation.org/show_bug.cgi?id=128312
--- Comment #9 from Mike Kaganski <mikekagan...@hotmail.com> ---
(In reply to b. from comment #7)
Bug 130221 was rightfully closed as duplicate of this; and this was rightfully
closed NOTABUG.
> these wrong calculations are! mistakes! period, duplicate ans 'NOTABUG' is
> misleading,
>
> they are errors because calc - and other spreadsheets? - give results that
> are not mathematically correct.
>
> one might discuss whether they are unsolvable errors and leave them as they
> are, but one shouldn't try to convince normal people with normal
> mathematical education that they are not errors. This will always and again
> cause endless discussions.
Now you mix *three* different things: "bug", "mistake", and "error"; and also
use ambiguous word "misleading". Bug tracker is only and exclusively a tool for
tracking *bugs* of this software, not anything that is not a bug, even if it
has "error" from mathematical point of view. So *first* thing to learn and
accept is to avoid any reference to "errors", and only speak about bugs. Bug
tracker does not have to "convince normal people" in anything; it simply states
if something is *issue in the software*. If you don't accept that, you are
spammer. Period.
Spreadsheet applications are created to perform machine calculations. They have
well-known limitations, like those that result from requirement of performance:
these applications are necessarily only perform mathematics on system hardware
(e.g., CPU), without using complex software calculations, which could in theory
provide some different (and sometimes mathematically more correct) results.
That is not something to be changed in Calc in any foreseeable future; and
unless there is a way to perform more precise calculations on hardware, any
duplicate of this bug is NOTABUG (but ignorance of submitter, or in case when
someone has already been informed, stubbornness or trolling).
Currently, the predominant computer architecture uses binary representation of
numbers, specifically in case of floats (which are universally used for any
numbers in spreadsheet software) - IEEE 754-1985. These numbers represent
arbitrary decimal numbers with limited and specified precision; hardware
operations on these representations give specific *errors* in results (which
are *not* bugs!); and that is expected and normal state of things. This is the
state of the art and standard of the industry; and again - this is not to be
"discussed in depth", or argued with developers, wasting their time the
thousandth time in need of explaining the same thing to just another person who
happens to dislike reading what is already told many times.
> ex$el and g$$gle have - according to comments in other threads - at least
> partially concealed the problem with rounding,
That was shown false: see comment 4 and comment 5. Repeating a false statement
ad nauseam does not make it true.
> @Mike has fixed a variant /
> consequence of these rounding errors in #129606, so improvements are!
> possible.
A fix in an interactive operation that is known to (1) usually require small
precision; (2) not to have mission-critical consequences of small
(in)accuracies resulting from applied extra rounding; and (3) be not
performance-critical (because it's a UI operation) can *not* be extrapolated to
any other calculation in spreadsheet, for which any of these points might not
hold. E.g., even ignoring accuracy problems that might arise from these
roundings (guess what: if there were universal rounding algorithms that
magically make *binary number* calculations *more* correct, they would be
already be in standard, and implemented), the operation would add huge
performance penalty, which would put system working with any descent
spreadsheet to its knees.
> i had suggested to check an eventually fundamental improvement in #130221 -
> allegedly the IEEE has taken the problem into account and with the IEEE
> standards 754-2008 and 754-2019 allows to calculate decimal numbers without
> rounding errors -
>
> imho it is worth at least a check or test if:
> - something like this could be implemented, maybe in future releases, and
> - if calc and the developers can get out of many stupid requests that way,
> and
> - whether calc could positively distinguish itself from other spreadsheets
> by solving this issue.
A new standard does not change anything by itself. Are you such a day-dreamer
that you imagine that any standard would magically get implemented in your
hardware just because it has magic "IEEE" letters? Read the Wikipedia article
[1], which explicitly tells "Discussed but not included". No hardware
implements that standard; neither there is a hardware implementing IEEE
754-2019, so nothing to discuss here, too.
> the practice of dismissing any suggestion for improvement as a duplicate of
> old bugs (that no developer will look at anymore because they are grown too
> long and perhaps awkwardly presented at first), i feel to be ... suboptimal.
Your feelings are irrelevant here. Any issue in bug tracker has, as already
mentioned, only one purpose: allow *developers* have a tidy list of something
to work on. This issue is nothing to work on. You need to tune your
expectations.
> it continues to provide the 'administrators' with a lot of administrative
> work, yes, but it doesn't move the project forward.
... and exactly closing something that is not to be worked on *does* help move
project forward, just by making a clear list of actually improvable stuff. Bug
tracker is not a place for metaphysical muses about "what place this works
should have been".
[1] https://en.wikipedia.org/wiki/IEEE_754-2008_revision
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
