Bug 131163 - Implement Ryu float-to-text algorithm (at least for non-locale-dependent cases)
Summary: Implement Ryu float-to-text algorithm (at least for non-locale-dependent cases)
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-03-05 17:02 UTC by Mike Kaganski
Modified: 2020-05-17 18:12 UTC (History)
0 users

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Kaganski 2020-03-05 17:02:04 UTC
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
Comment 1 Buovjaga 2020-05-17 18:12:45 UTC
Yep -> NEW