[Libreoffice-bugs] [Bug 131163] New: Implement Ryu float-to-text algorithm (at least for non-locale-dependent cases)

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=131163

            Bug ID: 131163
           Summary: Implement Ryu float-to-text algorithm (at least for
                    non-locale-dependent cases)
           Product: LibreOffice
           Version: unspecified
          Hardware: All
                OS: All
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: medium
         Component: LibreOffice
          Assignee: libreoffice-bugs at lists.freedesktop.org
          Reporter: mikekaganski at hotmail.com

We use O(U)String::number() rather extensively to produce locale-independent
numeric representation, e.g. when saving files. It uses
rtl_math_doubleTo(U)String, which in turn uses our own algorithm in
doubleToString (see sal/rtl/math.cxx).

First thing to note with the said algorithm produces values that don't
round-trip reliably. Then, the performance of it (using multiple floating-point
divisions) could be sub-optimal.

There's a Ryu algorithm [1] to produce unformatted locale-independent
reliably-roundtripping shortest possible (in terms of output decimal places)
strings from floating-point values, that is currently considered the fastest;
it is said to out-perform best previous algorithms not by tens of percents, but
by factor of 5x-20x. It was recently used in implementation of std::to_chars,
and suggested for libc++ [2].

However, the function isn't yet available in both clang and gcc (and it will
take time until the baseline versions of those will include that). Also we
could want to tweak the code to work directly on UTF-16 buffers to avoid
overhead; to have Ryu-printf automatically stripping trailing zeros, etc.

So the task is to implement the algorithm in core, for use in cases where we
produce numbers not intended for display (or maybe even for those cases?
shortest possible should mean they would be rounded towards the neater
alternative?)

[1] https://github.com/ulfjack/ryu
[2] https://reviews.llvm.org/D70631

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20200305/b2c389b1/attachment-0001.htm>