Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Wed, 17 May 2023 09:09:18 -0400
From: Rich Felker <dalias@...c.org>
To: newbie nullzwei <newbie-02@....de>
Cc: musl@...ts.openwall.com
Subject: Re: Re: DTOA: question about rendering / code pointer

On Wed, May 17, 2023 at 09:41:03AM +0200, newbie nullzwei wrote:
> 
> @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'.

There is no inaccuracy of the binary representation. It's an exact
number. The calculation that led to it might have been exact, but
floating point represents particular exact diadic rational numbers.
The musl list is not really the venue to argue over a philosophy that
they should be interpreted differently than how they're specified.

> 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 ).

I don't have particular knowledge/experience with the algorithms to
get shortest-round-trip forms. The implementations we have for
conversion are largely straightforward decimal (base-1-billion) bignum
with only a scaling operation (by powers of two) implemented on each.
The decimal to binary direction in particular has comments explaining
the steps.

Identifying what changes you would have to make to code like this to
get the behavior you want seems like a nontrivial math problem. You're
welcome to pursue it for your purposes in reusing the code, but I
still think you'd be better off finding a suitably-licensed and
suitable-language implementation of a known-good algorithm for what
you want, or reading some of the literature to figure out how to write
your own.

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.