NaN and infinity. Was Re: Some small requests for the next release

[Rici Lake <lua@...>]

I think we agree about math.nan. The infinities are a different issue, 
though. (I still think the best way of handling NaN's is to make them 
test false; that explicitly does not require a math.nan constant; 
indeed, the semantics of NaN don't really fit with the semantics of 
what a constant is.)

A function which simply requires math.max ought to work in either 
integer or floating-point compiles. That means having an integer 
counterpart to the math library, which is what I do.

It is then useful to have a standard math.infinity constant, 
implemented by the appropriate math library.

As always, I argue for the definition of interfaces independent of the 
implementation of libraries. It is certainly possible to define how 
math.max behaves without knowing whether Numbers are integers, exact 
bignum rationals, or inexact floating point (with some precision). In 
all of these cases, +/- infinity are useful values for iterative calls 
to max.

Obviously, an integer math library cannot implement the transcendental 
functions, amongst other things. I don't see this as a problem: my view 
is that two implementations of the same library (over different 
domains) need not implement all the same functions, but if they happen 
to implement the same functions, they should do so in the same way -- 
and if the same sort of functionality is available in both domains, the 
same functions should be used. I would apply this as well to os-type 
libraries, for example. This avoids the need for additional capability 
tests: the capability exists if the well-known method name is in the 
library table.

R.

On 2-Mar-05, at 1:24 PM, Roberto Ierusalimschy wrote:

> > > Is there any reason why anyone would use such library in that case?
>
> > If they haven't, then the assignment will crash and burn, which is not
> > desirable either.
>
> I think there is some noise here. I mean, why someone would load
> (require) such library without needing it? That code does not crash or
> burn unless you require it.
>
> My point is: anyone that really feels the need for "math.nan" can
> define it. Period. (People that use integer Lua seldom should have such
> feelings.)
>
> -- Roberto