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.