mathlib

classic Classic list List threaded Threaded
238 messages Options
1234 ... 12
Reply | Threaded
Open this post in threaded view
|

mathlib

Roberto Ierusalimschy
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

Reply | Threaded
Open this post in threaded view
|

Re: mathlib

Coda Highland
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 in-place doesn't help readability at all).

/s/ Adam

Reply | Threaded
Open this post in threaded view
|

Re: mathlib

Ryan Pusztai
In reply to this post by Roberto Ierusalimschy

On Thu, Apr 3, 2014 at 4: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.)

Probably can be removed. 

- deg, rad, pow: trivially done without the library.
 
Personally I would keep these because they seem to round a math library out. I know they are simple, but to the user if they are there they are free.
--
Regards,
Ryan
Reply | Threaded
Open this post in threaded view
|

Re: mathlib

Hao Wu
In reply to this post by Coda Highland
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 in-place 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
>

Reply | Threaded
Open this post in threaded view
|

Re: mathlib

Julien Cornebise
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 non-integer 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

Reply | Threaded
Open this post in threaded view
|

Re: mathlib

Coda Highland
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 non-integer 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

Reply | Threaded
Open this post in threaded view
|

Re: mathlib

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


On Thu, Apr 3, 2014 at 11:01 PM, Coda Highland <[hidden email]> wrote:
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 non-integer 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


Reply | Threaded
Open this post in threaded view
|

Re: mathlib

Gabriel Duarte
In reply to this post by Coda Highland

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 non-integer 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

Reply | Threaded
Open this post in threaded view
|

Re: mathlib

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


On Thu, Apr 3, 2014 at 10: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.)

- deg, rad, pow: trivially done without the library.

Comments?

-- Roberto


Reply | Threaded
Open this post in threaded view
|

Re: mathlib

Michel Martens
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.

Reply | Threaded
Open this post in threaded view
|

Re: mathlib

Ross Bencina
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
non-linear 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.

Reply | Threaded
Open this post in threaded view
|

Re: mathlib

Ross Bencina
In reply to this post by Michel Martens
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 non-trivial to implement. So you need to load a C lib. Why not
the standard Lua math lib? It is a *math* lib.

Ross.

Reply | Threaded
Open this post in threaded view
|

Re: mathlib

Michel Martens
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 non-trivial 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.

Reply | Threaded
Open this post in threaded view
|

Re: mathlib

Tim Channon
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
>
>


Reply | Threaded
Open this post in threaded view
|

Re: mathlib

Coroutines



On Thu, Apr 3, 2014 at 7:47 PM, Tim Channon <[hidden email]> wrote:
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
>
>

I usually use sin, cos, and tan for testing out graphing libraries, for simple (but complex looking) plots.  I wish these 3 would stay, but I'm not a math person -- can they be easily added back by use of the other functions?

I agree that pow() can go, we do have ^...   how would deg() and rad() be trivially added back?  Anything to do with degrees and radians scar[e]s me. 
Reply | Threaded
Open this post in threaded view
|

Re: mathlib

Paul Baker
> how would deg() and rad() be trivially added back?

deg & rad simply perform a division & multiplication by (PI / 180.0).

Reply | Threaded
Open this post in threaded view
|

Re: mathlib

Coroutines
On Thu, Apr 3, 2014 at 8:20 PM, Paul Baker <[hidden email]> wrote:
> how would deg() and rad() be trivially added back?

deg & rad simply perform a division & multiplication by (PI / 180.0).


Hmm.  So the argument is some of these math functions are trivial (if not rarely used), and my counter-argument is that the ones that build on others should remain if their triviality isn't known off the top of the common persons' head.
Reply | Threaded
Open this post in threaded view
|

Re: mathlib

Rena
On Thu, Apr 3, 2014 at 11:32 PM, Coroutines <[hidden email]> wrote:
On Thu, Apr 3, 2014 at 8:20 PM, Paul Baker <[hidden email]> wrote:
> how would deg() and rad() be trivially added back?

deg & rad simply perform a division & multiplication by (PI / 180.0).


Hmm.  So the argument is some of these math functions are trivial (if not rarely used), and my counter-argument is that the ones that build on others should remain if their triviality isn't known off the top of the common persons' head.

I can see removing pow() because there's already an operator for it, and maybe even deg()/rad() because they're pretty trivial (although their presence makes code nice and readable and I have to wonder how much good removing them would do). But removing sin(), cos(), and tan() would be ridiculous, and the other trig functions are also tremendously useful.

--
Sent from my Game Boy.
Reply | Threaded
Open this post in threaded view
|

Re: mathlib

steve donovan
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.

Reply | Threaded
Open this post in threaded view
|

Re: mathlib

Sven Olsen
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