
1234
... 12

We are considering removing some functions from the standard math lib,
either because we think few people use them or because they are trivially
implemented without the library. The current list is this:
 sinh, cosh, tanh: (They are quite specialized, on par with several
other functions offered by external libraries, such as lhf's mathlibx.)
 deg, rad, pow: trivially done without the library.
Comments?
 Roberto


On Thu, Apr 3, 2014 at 1:35 PM, Roberto Ierusalimschy
< [hidden email]> wrote:
> We are considering removing some functions from the standard math lib,
> either because we think few people use them or because they are trivially
> implemented without the library. The current list is this:
>
>  sinh, cosh, tanh: (They are quite specialized, on par with several
> other functions offered by external libraries, such as lhf's mathlibx.)
I can get behind this; hyperbolic geometry isn't particularly common.
>  deg, rad, pow: trivially done without the library.
I agree for removing pow, but not for deg and rad. Yes, it's trivially
done, but having it defined in the library does make the code more
readable and saves having to memorize the formulas (which are simple
but using it inplace doesn't help readability at all).
/s/ Adam


In reply to this post by Roberto Ierusalimschy


On Thu, Apr 3, 2014 at 1:41 PM, Coda Highland < [hidden email]> wrote:
> On Thu, Apr 3, 2014 at 1:35 PM, Roberto Ierusalimschy
> < [hidden email]> wrote:
>> We are considering removing some functions from the standard math lib,
>> either because we think few people use them or because they are trivially
>> implemented without the library. The current list is this:
>>
>>  sinh, cosh, tanh: (They are quite specialized, on par with several
>> other functions offered by external libraries, such as lhf's mathlibx.)
>
> I can get behind this; hyperbolic geometry isn't particularly common.
>
>>  deg, rad, pow: trivially done without the library.
>
> I agree for removing pow, but not for deg and rad. Yes, it's trivially
> done, but having it defined in the library does make the code more
> readable and saves having to memorize the formulas (which are simple
> but using it inplace doesn't help readability at all).
+1. At least, I know for games, it will be easier if deg/rad are there for free.
>
> /s/ Adam
>


In reply to this post by Roberto Ierusalimschy
Hi Roberto
Naive question, but doesn't math.pow() implements some fast exponentiation scheme (for integer exponents) that would be somewhat annoying to recode manually? Similar question for the exponentiation by noninteger exponents: I'd assume that math.pow() has some smarter way than exp(a log(x)). Or am I missing something obvious when you say it would be trivially done without the library?
All the best,


On Thu, Apr 3, 2014 at 2:57 PM, Julien Cornebise
< [hidden email]> wrote:
> Hi Roberto
>
> Naive question, but doesn't math.pow() implements some fast exponentiation
> scheme (for integer exponents) that would be somewhat annoying to recode
> manually? Similar question for the exponentiation by noninteger exponents:
> I'd assume that math.pow() has some smarter way than exp(a log(x)). Or am I
> missing something obvious when you say it would be trivially done without
> the library?
> All the best,
>
> Julien
>
The thing about math.pow is that Lua has exponentiation available
using the ^ operator  that is, math.pow(a,b) == a^b. The math
library function is therefore a more verbose and (I think) slightly
slower way of expressing the same thing.
/s/ Adam


Thanks Adam, much useful, I overlooked this. So, yes, I was missing something obvious :)


I think that math.pow can be removed, but the other ones should remain, even if they're easy to implement.
Em 03/04/2014 19:01, "Coda Highland" < [hidden email]> escreveu:
On Thu, Apr 3, 2014 at 2:57 PM, Julien Cornebise
<[hidden email]> wrote:
> Hi Roberto
>
> Naive question, but doesn't math.pow() implements some fast exponentiation
> scheme (for integer exponents) that would be somewhat annoying to recode
> manually? Similar question for the exponentiation by noninteger exponents:
> I'd assume that math.pow() has some smarter way than exp(a log(x)). Or am I
> missing something obvious when you say it would be trivially done without
> the library?
> All the best,
>
> Julien
>
The thing about math.pow is that Lua has exponentiation available
using the ^ operator  that is, math.pow(a,b) == a^b. The math
library function is therefore a more verbose and (I think) slightly
slower way of expressing the same thing.
/s/ Adam


In reply to this post by Roberto Ierusalimschy
Personally I'd keep the deb/rad/pow functions.


In reply to this post by Roberto Ierusalimschy
On 3 April 2014 17:35, Roberto Ierusalimschy < [hidden email]> wrote:
> We are considering removing some functions from the standard math lib,
> either because we think few people use them or because they are trivially
> implemented without the library.
All of them can go, in my opinion. By the way, I love this mindset.


In reply to this post by Roberto Ierusalimschy
On 4/04/2014 7:35 AM, Roberto Ierusalimschy wrote:
> We are considering removing some functions from the standard math lib,
> either because we think few people use them or because they are trivially
> implemented without the library. The current list is this:
>
>  sinh, cosh, tanh: (They are quite specialized, on par with several
> other functions offered by external libraries, such as lhf's mathlibx.)
I think that these are important to retain. I have used them. They are
useful for signal processing (computing coefficients for filters, or
nonlinear clipping curves). This has utility when using Lua for control
applications and possibly for dynamic simulations in games too.
>  deg, rad, pow: trivially done without the library.
I don't care for rad or deg, but I see some benefit to retaining pow for
closer syntactic compatibility with C code. Of course it can be defined
by the user, so pow is not as important to keep as sinh, cosh, tanh.
My take on it is that math should support all the special functions
provided by ANSI/ISO C.
Ross.


On 4/04/2014 9:35 AM, Michel Martens wrote:
>> We are considering removing some functions from the standard math lib,
>> >either because we think few people use them or because they are trivially
>> >implemented without the library.
>
> All of them can go, in my opinion. By the way, I love this mindset.
Perhaps we should get rid of sin/cos/tan and friends too then?
Special functions will always be used sparingly in any code, yet they
are very nontrivial to implement. So you need to load a C lib. Why not
the standard Lua math lib? It is a *math* lib.
Ross.


On 3 April 2014 21:25, Ross Bencina < [hidden email]> wrote:
> Perhaps we should get rid of sin/cos/tan and friends too then?
>
> Special functions will always be used sparingly in any code, yet they are
> very nontrivial to implement. So you need to load a C lib. Why not the
> standard Lua math lib? It is a *math* lib.
I think the idea is not whether or not it's a good idea to have a math
library, but instead where to draw the line. More functions exist in
the world than what's implemented in the math library, and that's only
because someone has drawn a line before. And now, they are asking if
the line should/could be redrawn. So even if it's a math lib, I'm fine
with it having less code than what it currently has. It's only my
opinion, of course.


In reply to this post by Roberto Ierusalimschy
I use all of them.
On 03/04/2014 21:35, Roberto Ierusalimschy wrote:
> We are considering removing some functions from the standard math lib,
> either because we think few people use them or because they are trivially
> implemented without the library. The current list is this:
>
>  sinh, cosh, tanh: (They are quite specialized, on par with several
> other functions offered by external libraries, such as lhf's mathlibx.)
>
>  deg, rad, pow: trivially done without the library.
>
> Comments?
>
>  Roberto
>
>


> how would deg() and rad() be trivially added back?
deg & rad simply perform a division & multiplication by (PI / 180.0).


On Fri, Apr 4, 2014 at 7:25 AM, Rena < [hidden email]> wrote:
> removing them would do). But removing sin(), cos(), and tan() would be
> ridiculous, and the other trig functions are also tremendously useful.
Original proposal is just for hyperbolic versions to be left out (sinh, cosh...)
Never had a use for them (in Lua) so can't comment.


In reply to this post by Roberto Ierusalimschy
 sinh, cosh, tanh: (They are quite specialized, on par with several
other functions offered by external libraries, such as lhf's mathlibx.)
These come up frequently enough in animation and graphics contexts that I'd vote to keep them around. Analytic solutions to differential equations are useful when simulating motion; and they often involve hyperbolic trig functions. (Tanh, for example, is the right behavior for the speed of an object falling in the presence of air resistance. It's also a relatively nice sigmoidal function, and those are handy in all sorts of data smoothing tricks.)
 deg, rad, pow: trivially done without the library.
Pow we can certainly do without; but, it's nice to work in a language where everyone doesn't need to define their own version of deg and rad. Just having standardized names is helpful.
Sven

1234
... 12
