Re: mathlib

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

On Saturday, April 5, 2014, Luiz Henrique de Figueiredo <lhf@tecgraf.puc-rio.br> wrote:
> > If anything, I think math.rand should be removed, if it cannot reasonably
> > be improved within the design limitations set for Lua.
>
> I don't think the design is wrong. Like I've mentioned here before, I was
> under the impression that modern libc had reasonable rand(), though I
> can't find a reference for that. In any case, there is nothing wrong with
> the specs of rand() in C. It is just that traditionally rand() has been
> implemented as a simple linear congruential generator. There is nothing to
> prevent rand() in libc to be much better than that. I never understood why
> BSD introduced random() when all it needed to do was to provide a better
> rand(), except that random() and then rand48() family generate long, not
> int. This was probably deemed important when int had 16 bits but is moot
> now.
>
> The intention of math.random() in Lua is to provide a convenient way
> to generate random nummbers on Lua for simple applications like games,
> simulations, and even throw-away passwords. Sophisticated applications such
> as crytpography and serious simulations, have other needs and a better
> served by specialized libraries such as OpenSSL. No one writing such an
> application would rely on any built-in random number generator anyway.
>
> Given this, Lua relying on rand() from C is not a bad choice, but it
> warrants that note in the manual.

Okay. I understand your point. In the case that it was understood differently, when I say design limitations of Lua, I mean that as a high compliment.

There is probably a broad misunderstanding surrounding rand, or at least I have it and have heard others share it.  It is not as much about it's not-quite-random nature as it is about generating seeds that appear to offer little variation in randomness. 

There are excellent reasons for this and, thanks to yours and others explanations, I now understand them, too. You and I may sit before that behavior and be comfortable with it and do the necessary things required to make it work. 

So I will ask: Is your target for the Lua language (distinct from Lua API) people who have that kind of understanding of C and it's library's limitations? Should they be expected to educate themselves in that way, in order to use them? Should they be expected to read the documentation's disclaimer about its use and then now where to go to find out how to get it to do what they're expecting?

If yes, then that approach is reasonable and relevant. If not, then It isn't. There may be other reasons to conclude that the status quo is best, but it's technical correctness would not be one of them, to me. It's too surprising. 

-Andrew

-Andrew