[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <CSNYLTX87JRO.1TEYSAWO9P81H@sumire>
Date: Tue, 16 May 2023 21:46:29 +0200
From: "alice" <alice@...ya.dev>
To: <musl@...ts.openwall.com>, "newbie nullzwei" <newbie-02@....de>
Subject: Re: DTOA: question about rendering / code pointer
On Tue May 16, 2023 at 9:36 PM CEST, Rich Felker wrote:
> On Tue, May 16, 2023 at 08:49:11PM +0200, newbie nullzwei wrote:
> > ( apologize - re-tweet - 'plain text', hope that will work better |
> > apologize - re-tweet - now 'subscribed' - got the impression my
> > mails didn't make it through to the list while not subscribed? )
> >
> > hello @ all,
> >
> > gnumeric uses musl dtoa for rendering, and a self constructed
> > 'brute force' concept to find 'shortet round tripping' figures mostly
> > similar to https://www.exploringbinary.com/the-shortest-decimal-string-that-round-trips-may-not-be-the-nearest/
> >
> > we face the same issue as mentioned there, some powers of two
> > miss to get the shortest 'round tripping' string, but have assigned
> > another one digit longer string. Forcing to one digit less produces a
> > string one decimal off in last position, and not tripping back to
> > the original double.
> >
> > Example: 0x1p-44 ( 2^-44 ) is rendered to
> >
> > 5.6843418860808015E-14 when allowed 17 digits, for
> > 16 digits it switches to 5.68434188608080**1**E-14, which is
> > not too bad as the 'exact' decimal weight of the binary representative
> > is ~5.684341886080801486969E-14, thus undershot to ~15, but!
> > it points to a different double, and 5.68434188608080**2**E-14
> > would be a better choice as it round trips to the originating double
> > value. Affected ~46 integral powers of two in doubles, many more
> > with long doubles.
> >
> > Is there any hope musl could change that? provide it as an option?
> > Or can anyone give a code pointer or nearer explanation to enable
> > us to patch it for our 'exotic' use?
>
> musl always, and very intentionally, performs correct rounding
> according to the current rounding direction for all conversions
> to/from decimal. Getting the shortest decimal string that round-trips
> is a somewhat different problem, and not one libc has any API for. But
> if what you want is shortest string which round-trips, I think there
> are faster approaches than what musl does; ensuring exactness like we
> do is more work.
dragonbox/schubfach is probably exactly what you're looking for, for which
a (c++) reference implementation is at
https://github.com/jk-jeon/dragonbox
afaik libreoffice now uses this for the same usecase(?).
>
> Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
