|
Message-ID: <trinity-ed37f7ac-283e-4b00-a39f-fcae8d83ee80-1684309263348@3c-app-gmx-bap41> Date: Wed, 17 May 2023 09:41:03 +0200 From: newbie nullzwei <newbie-02@....de> To: musl@...ts.openwall.com Subject: Aw: Re: DTOA: question about rendering / code pointer @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.
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.