mathlib

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

On Saturday, April 5, 2014, Hisham <h@hisham.hm> wrote:
> On 5 April 2014 02:17, Andrew Starks <andrew.starks@trms.com> wrote:
>
> > If anything, I think math.rand should be removed, if it cannot reasonably be
> > improved within the design limitations set for Lua.
>
> It _might_ not be able to reasonably improve within the design
> limitations set of the official Lua _implementation_, but the Lua
> _language_ (which is, as I understand, what is described by the Lua
> Reference Manual) says only that the statistical properties of
> math.rand are undefined, and therefore implementors can and do improve
> on the vanilla implementation (as is the case, for example, from
> math.rand in LuaJIT; the Lua implementations that run on top of the
> JVM probably also implement math.rand with stronger PRNG's).
>
> In my personal experience, having math.rand around has been very
> useful and I knew the caveats of the function; they're written in the
> manual. I like both facts that (a) Lua provides the function and (b)
> its statistical properties are left undefined so that implementations
> can improve on it. And in many cases what the official implementation
> provides is really enough.
>
> In the end, learning to deal with PRNG's is part of the learning
> process of a programmer much like learning to deal with floating
> point, isn't it? (In the sense that the abstractions do leak and you
> have to come to terms with the way things are implemented.)

And each language draws that line in a different place, depending on the problems being solved and the audience for whom they're solving them. 

My users are professionals, but not professional programmers. I provide scripting to them and want the learning of this tool to be short and to be possible. It's a means to an end, not something they want to master 

This works here, because the behavior is not defined and i can provide something more that work well, without appearing separate from Lua, requiring me to provide independent documentation, beyond PiL or other general resources.

It's also why I drew the distinction between C API and the scripting language. 

What I'm greatful for learning, if I understood Roberto correctly, is that Lua's target user is the implementer of the language and not that implementor's users. By extension, this distenction can easily be lost, because I want a nice scripting language for my users. 

But it shows itself here. If I want a more accessible rand function (more of an illustrative example, not to be made into something major), I can implement it. 

> (Random thought of the day: it might have been educational if early
> programming languages had called their functions of this kind prand
> rather than rand... (OTOH, calling floating point numbers "float"
> rather than "rational" didn't entirely abolish the confusion around
> them...) )
>
> -- Hisham