<div dir="ltr"><div>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.</div><div><br></div><div>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:</div><div><br></div><div><a href="http://6.4.5./1p2">6.4.5./1p2</a></div><div>Each constant shall have a type and the value of a constant shall be in the range of representable<br>values for its type.</div><div><br></div><div>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.</div><div><br></div><div><br></div><div>6.5.1p6</div><div>If an exceptional condition occurs during the evaluation of an expression (that is, if the result is not<br>mathematically defined or not in the range of representable values for its type), the behavior is<br>undefined.</div><div><br></div><div>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.<br> </div><div><br></div><div>6.6.1[13</div><div>Each constant expression shall evaluate to a value that is in the range of representable values for its<br>type.</div><div><br></div><div>COMMENT -- RORV again refers to the type's values.</div><div><br></div><div>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.</div><div><br></div><div>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:</div><div><br></div><div>a) 0.1000...5 billion zeros...0001 </div><div>b) Any halfway case resolved by a similar trailing string of zeros and then perhaps a nonzero deciding value</div><div>c) Any halfway case just below the edge</div><div>d) 3.0e1000000...just 1 billion zeros...000</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">-Jerome Coonen<div> 650.996.4738</div><div> <a href="mailto:jcoonen@gmail.com" target="_blank">jcoonen@gmail.com</a></div></div></div></div></div>