Aw: Re: [musl] DTOA: question about rendering / code pointer

[newbie nullzwei <newbie-02@gmx.de>]

@Rich: thank you for fast comment,

> musl always, and very intentionally, performs correct rounding
according to the current rounding direction for all conversions
to/from decimal.

yes, there is a tension if and where 'correctly rounded' is still or
no longer useful. From a decimal point of view, and thus that of
many users, it loses usefulness at the point where it prefers the
inaccuracy of the binary representation over the decimal 'equivalent'.

> Getting the shortest decimal string that round-trips
is a somewhat different problem, and not one libc has any API for.

Accordingly, it is a weakness for decimal <-> binary compatibility
if libraries, API's ... do not take 'SRT' into account. Similar to
the even IEEE rounding mode 'ties to evil' ( where 'ties away from
zero' is often mentioned but not implemented except in round()
- and there insufficient ). This is also a huge buzzkill to get
decimal acceptable results with binary placeholder math.

> But if what you want is shortest string which round-trips, I think
there are faster approaches than what musl does; ensuring exactness
like wedo is more work.

I have also considered and researched alternatives, but it would
be a bigger change, and brings new, e.g. licensing difficulties.
The current best SRT solutions are not simpler, see ryu, Schubfach,
SwiftDtoa ... they are really clobbering to be accurate and fast,
I was positively surprised that musl added with trial and error
afterburner can keep up well.
If there is a version of your code with more comments, or if you can
explain to me where the last digit is constructed / rounded and which
variables mean what there, I would like to try to patch it. ( I know,
professionals read such like a shopping list, I unfortunately do not ).

@alice: thank you for fast comment,

> dragonbox/schubfach is probably exactly what you're looking for,
for which a (c++) reference implementation is at
https://github.com/jk-jeon/dragonbox

thanks for the hint, had already looked there, C++ is not an option
for gnumeric, and I didn't get all alternatives to work and test,
- ryu I have mostly ready, is difficult / somewhat slow for long
doubles, I couldn't yet convince the maintainer,
- SwiftDtoa - popped very well working out of the box, but there are
questions that Swits Apache License isn't compatible with GNU GPL2
which gnumeric wants to keep.

> afaik libreoffice now uses this for the same usecase(?).

I am surprised and happy that LibreOffice uses reasonable solutions,
but I am afraid that all profit will be lost in their unrestrained
prettyfying.