Re: Infinity (to the nearest integer)

General update: On October 17 I asked MarkM about what to do about  
this case. Our general conclusion is that, given that we already pay  
the implementation cost of integer values potentially being bignums  
(and therefore necessarily being at least tagged), there is no reason  
to avoid returning a non-integer value. The only other reasonable  
option, throwing, is likely to be even more expensive, and is not a  
good option for the caller handling the case (given sealed-exception).

For that last reason, and consistency, if we do that, it might also be  
worth returning the same value in the case of integer division by  
zero. Though considering that case (where division by zero usually  
indicates a program error) suggests that perhaps floor and round  
should throw instead.


On Oct 14, 2010, at 18:12, Jonathan S. Shapiro wrote:
> On Thu, Oct 14, 2010 at 2:26 PM, Kevin Reid <kpreid-M/[email protected]>  
> wrote:
>> I didn't ask "can we have an integer NaN". I asked "given that an
>> integer operation is going to return NaN, should it be distinct from
>> the float NaN?"
>
> Since there is no "the float NaN" (singular), the answer is clearly  
> no. Each floating point format has it's own NaN representation.

E generally chooses to work with only 64-bit floats as the default.  
Even if it did not, it does not follow that it is mandatory that 32- 
bit NaN is distinguished from 64-bit NaN. We already conflate all  
possible values of the I-forget-what-you-call-them extra data bits of  
the NaN.

However, all current implementations distinguish 32-bit NaN (if they  
have 32-bit floats) from 64-bit NaN, so that would be a change.

Even if we do not conflate all NaNs, it does not seem to me  
particularly terrible to choose float64 NaN as the non-integer object  
floor/0 and round/0 return when there is no integer to return. On the  
other hand, we could devise an 'integer NaN' object, which would have  
the advantage of being designed to correspond to the integer protocol  
rather than the float protocol.


>>> If infinity or NaN values of any sort are introduced, it is
>>> important that they have the same representation on all platforms.
>>
>> What do you mean by "representation"? The representation of values in
>> memory? On disk? Semantically visible distinctions?
>
> On reflection, I meant two things:
>
> 1. The same computation should produce the same result when executed  
> in the
> same precision w.r.t. all methods of observing the result.
>
> 2. There needs to be a consistent way of [de]serializing NaN/infinity.
>
> Unfortunately, [1] means in practice that a specific bit pattern  
> must be
> selected. This is true because untagged unions of non-pointer  
> scalars are
> generally treated as "safe" by current runtimes. Consider explicit  
> structure layout in .Net.

E does not have untagged unions.


 From elsewhere in the thread I see you are concerned with interfacing  
with other code on the same runtime. In general, E tends not to be  
transparent in this matter, due to the existence of resolved-promise  
values which must be treated identically to their referents, so we do  
not lose a whole lot by also needing to canonicalize NaNs (or similar  
actions) at such boundaries.

Given this information, do you have further comments?

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