[Cfp-interest 2138] Re: supernormal numbers (was: WG14 IEEE 754-C binding meeting minutes) 2021/08/17

[Jim Thomas]

> On Aug 18, 2021, at 8:25 AM, Vincent Lefevre <vincent at vinc17.net> wrote:
> 
> On 2021-08-17 14:02:43 -0500, Rajan Bhakta wrote:
>>    Number classification and normal numbers (See CFP2091-3, CFP2096).
> [...]
>>      Fred: There is also supernormal (double double has it). Do you know
>> if DBL_MAX + DBL_MAX is a finite number instead of an infinity.
> 
> Because the absolute value of the second component of a double-double
> number must be less than or equal to 1/2 ulp of the first component,

Does this mean all arithmetic operations preserve the property? Are the operations undefined for other inputs?

> DBL_MAX + DBL_MAX is an invalid representation (trap representation
> in the C terminology).
> 
> However, due to a representation issue with the maximum exponent,
> the maximum representable finite floating-point number LDBL_MAX is
> strictly larger than the maximum normalized floating-point number
> (which is close to DBL_MAX/2).
> 
> With GCC on PowerPC (double-double), where the precision is 106,

The double-double described in 

http://mrob.com/pub/math/f161.html <http://mrob.com/pub/math/f161.html>

claims the precision is 107, with the extra bit coming from the way the sign of the low component is used.

> 
> LDBL_MAX = 0x1.fffffffffffff7ffffffffffff8p+1023
> 
> which is
>           0x1.fffffffffffffp+1023
>         + 0x0.00000000000007ffffffffffff8p+1023
> 
> though I would rather expect DBL_MAX + DBL_MAX * DBL_EPSILON / 4
> = 0x1.fffffffffffff7ffffffffffffcp+1023, i.e. with an additional
> trailing 1. I don't see why this would be a trap representation.
> 
> However, the maximum normalized floating-point number is
> 0x1.ffffffffffffffffffffffffff8p+1022, or equivalently,
> 0x0.ffffffffffffffffffffffffffcp+1023, which is
> 
>           0x1.0000000000000p+1023
>         - 0x0.000000000000000000000000004p+1023
> 
> There's another issue:
> 
>  FLT_MAX_EXP
>  DBL_MAX_EXP
>  LDBL_MAX_EXP
> 
> are defined in th current C2x draft (N2596) as
> 
>  maximum integer such that FLT_RADIX raised to one less than that
>  power is a representable finite floating-point number, e_max
> 
> while e_max was first introduced in the floating-point model, i.e.
> for *normalized* numbers. A solution would be to introduce
> 
>  FLT_NORM_MAX_EXP
>  DBL_NORM_MAX_EXP
>  LDBL_NORM_MAX_EXP
> 
> which would follow the floating-point model, and
> 
>  FLT_MAX_EXP
>  DBL_MAX_EXP
>  LDBL_MAX_EXP
> 
> which would allow potentially larger values, possibly with a relaxed
> definition (the current one is OK when there are no supernormal numbers,
> but may be artificial otherwise).

I believe “floating-point number” was originally intended to refer to a model number. 5.2.4.2.2 still says that clearly:

For each floating-point type, a floating-point number (x) is defined by the following model:

An implementation could include other values in floating types, but defining and describing how such values fit into the specification for model numbers would be the implementation’s job. 

However, it’s easy and natural to interpret “floating-point number” as any number in a floating type. And efforts to support double-double formats have used that interpretation, e.g., in the definitions of FLT_MAX and FLT_NORM_MAX.

So what is a floating-point number? A number defined by the model, or a number in a floating type? Or is it one or the other depending on context?

What’s feasible for CFP to do about this?

- Jim Thomas

> 
> FYI, my original GCC bug report (submitted before the defect report,
> thus be careful with some obsolete discussion):
> 
>  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61399
> 
> -- 
> Vincent Lefèvre <vincent at vinc17.net> - Web: <https://www.vinc17.net/>
> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
> _______________________________________________
> Cfp-interest mailing list
> Cfp-interest at oakapple.net
> http://mailman.oakapple.net/mailman/listinfo/cfp-interest

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20210913/7bd3d7f4/attachment.htm>