[Cfp-interest 2664] Re: GB-287

[Mike Cowlishaw]

Understood ... I was trying to reply to the various accumulation of posts on
the subject, not specifically to yours.  And to clarify the use of 'format'
in 754.

Mike

> -----Original Message-----
> From: Jim Thomas [mailto:jaswthomas at sbcglobal.net] 
> Sent: 31 January 2023 14:44
> To: Mike Cowlishaw
> Cc: CFP; Joseph Myers
> Subject: Re: [Cfp-interest 2649] GB-287
> 
> This shows that IEEE 754 does not require conversion between 
> hexadecimal strings and decimal formats. But that's not the 
> rationale for having the strtodN functions accept hexadecimal 
> strings. IEEE 754 5.4.2 does require conversions between all 
> supported floating-point formats. We don't have any other way 
> of converting from non-arithmetic binary formats to decimal 
> formats without the hexadecimal support in strtodN. Joseph 
> explains the difficulties in [Cfp-interest 2657] Re: GB-287.
> 
> - Jim
> 
> > On Jan 31, 2023, at 2:24 AM, Mike Cowlishaw 
> <mfc at speleotrove.com> wrote:
> > 
> >> IEEE 754 requires correctly rounded conversions between 
> all supported 
> >> formats (arithmetic and non-arithmetic). Adding the hexadecimal 
> >> support completed the required conversions. See
> >> H.4.3 and the example in H.12.2.
> > 
> > Just to clarify, here, a 'format' in 754, as defined in 754 
> clause 3, 
> > does not include "External hexadecimal-significand 
> character sequences" as
> > described in 5.12.3.   The "strings in hexadecimal format" 
> phrase -- or
> > something like it -- was, I think used prior to the 2008 
> standard but 
> > we were careful this century to not use the word format 
> except for the 
> > use as in clause 3.
> > 
> > 5.12 does require exact conversions from binary formats to 
> hexadecimal 
> > strings, but not decimal:
> > "Implementations shall provide exact conversions from each 
> supported 
> > binary format to external character sequences representing numbers 
> > with hexadecimal digits for the significand, and shall provide 
> > conversions back that recover the original floating-point 
> > representation, except that a signaling NaN might be 
> converted to a quiet NaN. See 5.12.1 and 5.12.3 for details."
> > 
> > So I agree with Fred J. Tydeman, who wrote "there is NO requirement 
> > for conversions between hexadecimal strings and decimal 
> floating-point objects".
> > 
> > Mike
> > 
> > 
>