Re: [musl] DTOA: question about rendering / code pointer

[Rich Felker <dalias@libc.org>]

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