https://bugs.documentfoundation.org/show_bug.cgi?id=128312
--- Comment #8 from b. <newbie...@gmx.de> ---
two more comments ... sorry if I argue too persistently, i like improvements,
and contradiction or hastily supressing bugs as duplicate (especially of those
imho too hastily qualified as 'notabug') sometimes annoys me and sometimes
pushes me to contra-contradiction ... :
1. IEEE 754-2008 really promises to have a solution?
wikipedia about f.-p. accuracy problems and formats and a solution:
https://en.wikipedia.org/wiki/Floating-point_arithmetic#Accuracy_problems
citation:
'As decimal fractions can often not be exactly represented in binary
floating-point, such arithmetic is at its best (...) , and at its worst when it
is expected to model the interactions of quantities expressed as decimal
strings that are expected to be exact. An example of the latter case is
financial calculations. For this reason, financial software tends not to use a
binary floating-point number representation. The "decimal" data type of the C#
and Python programming languages, and the decimal formats of the IEEE 754-2008
standard, are designed to avoid the problems of binary floating-point
representations when applied to human-entered exact decimal values, and make
the arithmetic always behave as expected when numbers are printed in decimal.'
imho that qualifies for 'NOTABUG' being wrong, and a request for improvement
(an enhancement request?), being a valid and justified proposal as it would be
possible,
just my two cents ...
2. for those poor people who have to do financial / accountancy calculations in
spreadsheets ... :-( ... i have compassion with you ... a trick used by some
banks as well:
do the calculations with integer values representing the 'cents' (or whatever
your currency defines as minimum fractional part of it's units), and divide the
results for display if neccessary ...
e.g. =0,1 EUR + 0,1 EUR ... or similar may fail in some situations, while =10
cent + 10 cent ... (divided by 100) has a better chance for an exact result as
most integers have an exact representation in binary, (and in floating point /
IEEE 754?)
(not tested - short in time - just a stolen idea, but looks promising)
(pls. no arguing that 0,1 + 0,1 and most calculations will 'show' correct
results when displayed with 2 decimal digits, yes, i'm through with all that
stuff, problems will step in once you have 'if([0,12]=[0,12])' being false reg.
comparing 0,119999999... with 0,12000000000001... or similar, or when rounding
too often and too early to avoid carrying fractions, and thus sums of rounded
values deviate against the rounded of a sum, and different parts of your
software / your sheet use different approaches to the result ...)
(we / you had a proposal for IEEE 754-2008 5 years ago, see #76245, still
unanswered, and other bugs e.g. problems with large values as well, see #37923
and plenty bugs cited there)
reg.
b.
--
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
