Re: Infinity (to the nearest integer)

On Oct 26, 2010, at 15:59, Jonathan S. Shapiro wrote:

> I haven't tracked this topic in detail, so I may be misinterpreting  
> Kevin's statement above, but here is my concern:
>
> If an implementation chooses to distinguish 32-bit and 64-bit  
> floating point types, it absolutely must not return the same object  
> for NaN in the two cases. While E is dynamically typed, it is a  
> terrible idea to introduce behavior that reduces our ability to  
> statically type check portions of the language.


Do you mean type *checking*, or type *inference* and type-information- 
based optimization? For checking, i.e. reporting incorrect programs to  
the programmer, the checker need only care about semantically visible  
distinctions. For optimization, we need only transform the code such  
that we know that only the appropriate representation of NaN reaches  
that point.


That said, I think that this is a red herring: as I mentioned before,  
E consideres 64-bit floats to be the 'ordinary' floats. For example,  
'NaN' and 'Infinity' in the environment are bound to 64-bit float  
values, and there are no 32-bit float literals. Therefore, we can  
proceed considering 64-bit-NaN as the canonical NaN, and not attempt  
to conflate it with 32-bit NaN.


*That* said, I am becoming inclined to declare that .floor()  
and .round() throw on error, so as to keep NaN or similar values out  
of the 'programming with integers domain', for consistency with  
integer division by zero, and to avoid this whole representation issue.

The reason this issue is unclear is that we have an operation whose  
parameter is float and result is integer. The one precedent I know for  
having the floor operation return an integer, Common Lisp, leaves  
floating-point exceptional-case handling unspecified (it was written  
before the use of IEEE FP was universal) and so says nothing about  
what to do about NaN.

-- 
Kevin Reid                                  <http://switchb.org/kpreid/>