Re: mathlib

[Andrew Starks <andrew.starks@...>]

On Friday, April 4, 2014, Ralph Hempel <rhempel@bmts.com> wrote:
> Roberto Ierusalimschy wrote:
>
> > > To assist the team, here are the functions ready-coded in C89.
> > > These versions have been in use (by me only, AFAIK, although
> > > they are on my GitHub site in a package that I have not advertised)
> > > for more than a year.
> >
> > If those definitions are good enough, they can easily be implemented
> > in Lua itself by those that need them.
>
> Down this way lies madness. I feel strongly that the standard math functions that already exist in mathlib should stay there - with the possible exception of pow() because now there is ^
>
> Having everyone define their own deg() rad() .... etc leaves the question of will they do it right, will there be accidental pollution of namespace etc.

This is a false choice between an ANSI C89 subsetof math.h and nothing at all.  

> mathlib has always had a set of standard functions, and I don't believe that the code space is much of an issue except on extremely embedded systems, and there the integrator has the opportunity to remove certain functions. I have done this myself.

I believe that there is more to it than size of the library.  

> If we're arguing "Why not add asinh() etc and any shiny new C library functions" then I would counter with - put them in xmathlib or some new extended math library that is built as an option for those that need it.
>
> I think a small number of programmers will be surprised if basic functions that used to be available in mathlib disappeared.
>
> Thinking about this a bit more, I even checked back to make sure Roberto's original email was not dated April 1 :-)
>
> So my vote is leave it alone.
>
> Ralph

#1: Programmer uses Lua, needs deg, sees that it's there and uses it. They have no strong reaction because they expected it to be there, maybe even guessing that it was there and guessing at its arguments, using it without needing to read the reference guide. This is least surprising.

Later, programmer uses Lua's rand function. They see it's always returning the same results. They go on the list and find out that the rand function is based on ANSI C 89. They get into a short discussion about why this is the case and what they can do about it. The answers are reasonable but the surprise factor is nonetheless "high."

#2: Programmer uses Lua and needs deg, but doesn't find it. In fact they find that the math library has almost nothing in it. They look in the documentation and see that these are in a library, maybe that is included in the Lua distribution. They now have to type "require 'mathx'" or something. They do that and it works fine. This was a little surprising and it leaves them with the impression that Lua takes size extremely seriously. 

Later, pogrammer needs rand and loads it from mathx. It works as expected. They dig around and find a quite complete math library that seems to fit their needs quite well. Like Lua, it's fast and light, but because it's separate, the authors were able to put a bit more platform specific code, in order to make it more modern. 

There is a difference between the rest of Lua's library functions and the ones found in math that is important. Other Lua library functions deal with what is coming in (strings), what is going out (io) or dealing with structures and types (to*, table). There are also some basic so functions, but all of them are either supporting the language or helping it to interact with its host environment. 

The math library is an application library. If you're using Lua to do math, it's nice to have it right there. But given the nature of implementing certain math functions and the limitations of C89, this can sometimes be limiting, so it's a limited library, at that. It attempts to provide people with what they would expect, but expectations are moving while ANSI C89 is not. 

Is it better to have a limited (sometimes surprisingly so) math library or a more we'll rounded separate library? Or is it better to have an even more limited math library?

If anything, I think math.rand should be removed, if it cannot reasonably be improved within the design limitations set for Lua. This function illustrates the point that I'm attempting to make, better than anything else I can point to. 

I didn't mean to drag this off from the original question. 

-Andrew