lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

A lot of good discussion has come out the math.nan thread. Roberto proposed an elegant solution in the Lua tradition of a minimal library implementing various NaN related functionality. Whilst this solution works, it misses part of the point of the discussion. Lua provides an arbitrary(as far as I can tell) subset of POSIX math functions and a constant (pi), which are in turn are a random subset of the universe of useful functions and constants. Over time, people will want new ones added and some kind of societal mechanism should evolve for this to happen. Clearly the barrier to adding functionality to library should be much lower than adding to the core as so much work has been done to make them optional. Having said that, there is also a need to provide a convenient common set of functionality that people can expect to be available. Going back to the NaN case in particular, the reason I think that it should be supported in the core is twofold: 
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 Unix---Linux 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 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