Re: Infinity (to the nearest integer)

On Thu, 2010-10-14 at 17:26 -0400, Kevin Reid wrote:
> [This is a combined reply to several messages.]
> 
> On Oct 14, 2010, at 16:00, Karp, Alan H wrote:
> 
> > Kevin Reid wrote:
> >>
> >> Suppose we do want to produce NaN. Why do we need integer NaNs
> >> distinct from float NaNs?
> >>
> > Because every bit pattern in an integer register is a valid fixed  
> > point number, which leaves no way to denote NaN.
> 
> You've just argued *against* having an integer-NaN value, it seems to  
> me.
> 
> 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?"
> 
> No matter what we decide .floor() (which, to review, is an operation  
> taking a double and returning a bigint) does in the inf/NaN cases,  
> *something* other than 'put the result into an integer register' has  
> to happen (unless we decide to return 0). I don't see that any of the  
> options (throw, "integer NaN" which in practice would be an arbitrary  
> object pointer from the perspective of the runtime, or double NaN) is  
> going to be notably *more* expensive in the Hypothetical Optimizing  
> Implementation.

Note, there's a "Hypothetical Optimizing Implementation" on one of my
branches somewhere ;-) If it knows that an object is of type float64 and
you call a method (e.g. floor/0) on it, then it attaches the method's
return type to the result.

If you call a method on that, it will shorten the call (i.e. look up the
Java Method at compile time) when possible. This works better if it's
defined to return e.g. EInt rather than Object.

(there are some issues about non-final types and ambiguous overloads I
need to work out before it's usable though)


-- 
Dr Thomas Leonard
IT Innovation Centre
2 Venture Road
Southampton
Hampshire SO16 7NP

Tel: +44 0 23 8076 0834
Fax: +44 0 23 8076 0833
mailto:tal-v5nx5w6akNyLE8xUarVfuPLx9OUvmyODWmv/[email protected]
http://www.it-innovation.soton.ac.uk