[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: mathlib
- From: Justin Cormack <justin@...>
- Date: Sat, 5 Apr 2014 10:09:14 +0100
On Sat, Apr 5, 2014 at 6:17 AM, Andrew Starks <andrew.starks@trms.com> wrote:
> 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?
Agreed. And the quality of it depends on your libc implementation,
which will vary, which is a big problem if you actually want to use it
for serious stuff. There is a big problem about test coverage, eg if
one platform has rounding issues in a maths function, Lua will differ
and might be incorrect, while a standalone library can have test cases
and be consistent.
> 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.
Definitely. Whether a better one should be provided (like LuaJIT does) though?
Justin