[cfp-interest 4008] Re: Action: range of representable numbers

[Jerome Coonen]

Greetings, this note pertains to my related email of 23 Sept and Joshua's
response. I've extracted what I think is the key issue, removing all the
machinery of the proposal, which can wait.

What is the meaning of "range of representable values" (RORV) when it comes
to floating-point types? Here are three essential statements, drawn from
the 11 instances:

6.4.5./1p2
Each constant shall have a type and the value of a constant shall be in the
range of representable
values for its type.

COMMENT -- The "value" of a constant like 0.1 is the representable value it
projects onto in the arithmetic of the base conversion. Here, RORV refers
to just values representable in the target type.


6.5.1p6
If an exceptional condition occurs during the evaluation of an expression
(that is, if the result is not
mathematically defined or not in the range of representable values for its
type), the behavior is
undefined.

COMMENT -- Again, RORV refers specifically to the type's representable
values. In fact, this statement is incorrect. An expression that reduces to
0./0. is not "mathematically defined", but since the 1980s FPUs have
addressed the matter with NaNs, which are representable values. The case
"not mathematically defined" is redundant without NaNs and unnecessary with
them.


6.6.1[13
Each constant expression shall evaluate to a value that is in the range of
representable values for its
type.

COMMENT -- RORV again refers to the type's values.

I believe a source of confusion here is the distinction between the values
representable in any type and the set of all mathematical values that
"project" onto them in the process of base conversion or expression
evaluation. These processes lie partiually outside the scope of C.

To be a bit pedantic, Joshua seems to  refer to the "preimage" of a type's
representable values, that is, the set of values that project onto them.
That set of values is hard to talk about and fortunately it's unnecessary
to do so in the draft. Here are a few simple examples:

a) 0.1000...5 billion zeros...0001
b) Any halfway case resolved by a similar trailing string of zeros and then
perhaps a nonzero deciding value
c) Any halfway case just below the edge
d) 3.0e1000000...just 1 billion zeros...000

Compilers have limits on the input strings they accept. Conversion routines
have other limits.  What's clear is that preimage of any computer number
system can never be considered "all real numbers" simply because we tack
useful infinity symbols, signed or unsigned, onto the system.

Returning to the underlying subject, my view is that the standard should be
as concise as possible. In floating point, we work in a finite, discrete
domain guided by the larger mathematical world. We should make our
mathematical statements carefully, and only when needed. The current
language in the sections I proposed to change blurs the line between
computer arithmetic and mathematics in a way I find misleading.

-Jerome Coonen
 650.996.4738
 jcoonen at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20260928/03aac21f/attachment.htm>