Re: mathlib

[Hisham <h@...>]

On 7 April 2014 15:02, Dirk Laurie <dirk.laurie@gmail.com> wrote:
>
> 2014-04-06 17:02 GMT+02:00 Roberto Ierusalimschy <roberto@inf.puc-rio.br>:
> >> [...] Of course, reasons are more important than mere votes [...]
> >
> > Well said. Reasons are *much* more important than mere votes for us.
> > More exactly, reasons count, votes do not.
>
> Apart from the statement "few people use them" that cannot
> be checked since votes do not count, the main reasons for
> removing sinh, cosh, tanh seem to be:
>
> 1. Those that want it removed don't use them.
> 2. Unlike sin, cos, tan, there is no asinh, acosh, atanh.
> 3. You don't learn about them already in high school.
> 4. You can always get them via mathx.
> 5. There are simple identities to express them in terms of exp.
>
> The main reasons for not removing them seem to be:
>
> 1. Those that do not want it removed use them.
> 2. Well then, supply asinh, acosh, atanh too.
> 3. You do learn about them at university.

Not everyone (I didn't learn it through my CS degree, and Roberto
didn't recall in his EE degree). Lua is hardly what you would call a
Math-focused language (even though a member of the triumvirat is a
mathematician!).

> 4. mathx won't compile under C89.

This is probably fixable (using the expertise listed in point 5 below).

> 5. The simple identities are perilous in floating point and
> the expertise to circumvent that is considerable.
>
> At this stage, as has been pointed out, it becomes sensible
> to compare gains with losses.
>
> Gains seem to be:
>
> 1. A few dozen bytes fewer in the executable. (Under `make linux`,
> the 5.2.2 executable size is 214708 vs 214894.
>
> 2. A few lines fewer in the documentation.
>
> 3. A warm feeling under the heart that creeping featurism is
> being combated by removing some features.
>
> Losses seem to be:
>
> 1. Some people will find their old programs breaking.

This is, to _me_, a strong point, but we've been through that in the
past (and will go through that in the near future) with much larger
breakage. The writings by the Lua authors on the design of the
language have time and again reiterated that they not afraid of
breaking existing code to keep the minimalism in the design.

> 2. It will no longer be true that "This library is an interface to the
> standard C math library." At mosy it will be an interface to some
> selected functions of that library.

Well, strictly speaking this hasn't been true for fifteen years.

> 3. A depressing feeling that Lua is going in a direction that
> is by design unsympathetic to those who know a little more
> mathematics than they teach you at school.

Well, I see no 3D matrix operations in the language either and I doubt
it is unsympathetic to those who use it for computer graphics
(incidentally, the area of another member of the triumvirat!) The same
argument applies for any other domain.

By that measure I could say that the removal of module() gave me a
depressing feeling that Lua was going in a direction that is by design
unsympathetic to those who want to use Lua for writing reusable code.
But we've crossed that bridge now — the LuaRocks codebase no longer
uses module(), and the code is no less modular. Life goes on,

> I possess an 86-piece drill and socket set. To date I have
> not yet used the 11mm socket, the 16 mm flat-bit wood
> drill, most of the variously shaped grindstones, and quite
> a few others. But I know that they are there. That's rather
> how I feel about the current Lua standard libraries.

That's just how I felt about the 450+ functions available in the
standard library of CA Clipper.

On this whole discussion, if there are functions to go away, it seems
the only one that's really a no-brainer for removal is math.pow. Yet,
by the same logic, another clear candidate for removal which I haven't
seen mentioned is string.len (curiously, I used it for the first time
in _years_ last week as an argument for a map-like function — I guess
that's why I remembered it exists; wouldn't mind using `function(x)
return #x end` in its place though).

-- Hisham