
1) It is a very useful "constant" that simplifies many arithmetical operations as was recognized when IEEE added it to the standard. By way of analogy, imagine an Excel spreadsheet complaining that "#N/A is not a number" in all its formulae! Throwing errors is not always the best solution. 2) I have know way of knowing if the 0/0 or the "if x ~= x" tricks work on an arbitrary architecture as they appear to be derived from IEEE behaviour. Having math.nan, math.isnan, etc as part of the porting process forces this to be made explicit in other environments, even if this means returning nil or an error. In the past I have been puzzled by the patchy treatment of this under UnixLinux has a MATH_NAN constant, Solaris did not and you had to roll your own.
Integer math arguments are a bit of a red herring as you would probably never, for example, use math.pi in an integer environment. Perhaps Rici's suggestion of having a hierarchy of functions is the way to go and explcitily indicating which ones are valid in various environments.
niklas
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 floatingpoint 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 ostype libraries, for example. This avoids the need for additional capability tests: the capability exists if the wellknown method name is in the library table.R. On 2Mar05, 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