From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 4649 invoked from network); 16 May 2023 19:36:43 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 16 May 2023 19:36:43 -0000 Received: (qmail 24060 invoked by uid 550); 16 May 2023 19:36:40 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 24028 invoked from network); 16 May 2023 19:36:40 -0000 Date: Tue, 16 May 2023 15:36:28 -0400 From: Rich Felker To: newbie nullzwei Cc: musl@lists.openwall.com Message-ID: <20230516193627.GM4163@brightrain.aerifal.cx> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] DTOA: question about rendering / code pointer 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. Rich