https://bugs.documentfoundation.org/show_bug.cgi?id=55960
--- Comment #32 from b. <[email protected]> --- Who the f... categorized this an easyhack? It's the! central problem of spreadsheets and other computer math programs trying to serve decimal expectations of users by raping binary floating-point math which is unsolved since decades. A.) bin-FP isn't "arithmetic", only an approximation, B.) same for human decimal math, C.) the approaches are different!, more than necessary, D.) "decimal" while not perfect is superior to "binary", thus difficult to substitute, E.) while e.g. "rounding" itself suffers from bin-FP imprecision there are no tools to handle reliably, F.) computers / IEEE 754 standard provide a more user friendly / user compatible alternative, decimal32, decimal64 and decimal128 types, alas unjustified neglected in favor of speed, speed, speed, G.) there is! a spreadsheet program available using it, gnumeric, not finished, "experimental", however solving these simple cases, and excel and LO calc file format compatible, H.) progress is possible, also in bin-FP, unfortunately it is very, very difficult in the muddled codebase of LO Calc and the uncoordinated thicket of hacks and patches, suggestions: 1.) untag "easyhack", 2.) set free from the idea of "Excel compatibility", it's okay for functionality, not for miscalculations, 3.) check the approach of gnumeric, 4.) if you try decimal-FP consider to use DPD encoding instead of BID, much better speed in conversions form / to decimal strings, relevant for files and! display, these conversions are a relevant bottleneck in using bin-FP for decimal tasks, at least for basic arithmetic involving decimal I/O on modern machines DPD encoded types outperform not only BID encoding but also bin-FP, I think reg. parallelization in conversions. -- You are receiving this mail because: You are the assignee for the bug.
