Re: mathlib

[Milind Gupta <milind.gupta@...>]

I think we need to just see if they are equivalent to the functions being removed from the library. If the math library functions have such quirks and if the replacement replicate them then they should not be missed from the library.

      Having such quirks may be a reason to support their removal because when you reach such conditions where you have to look at these things you may end up using your custom conditioned functions.

Milind

On Fri, Apr 4, 2014 at 5:11 PM, Sean Conner <sean@conman.org> wrote:

It was thus said that the Great Milind Gupta once stated:
> Hi,
>        Once these functions are removed don't we just have to include the
> following code in our Lua program if we use all these and we are good to go?
>

  [ functions snipped ]

> Would these not be equivalent?

  They may or may not be.  Floating point math is ... tricky.  The following
covers the topic in depth:

        http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html

There's also an overview of the issues (that might make for some easier
reading) at:

        http://floating-point-gui.de/

  The functions might be perfectly fine for some inputs, and blow up for
other inputs.  I don't know.  I know just enough to know that I don't know
enough.  For instance, this:

#include <stdio.h>
#include <stdlib.h>
#include <math.h>

int main(void)
{
  printf("%f\n",sin(3.14159265358979323846));
  return EXIT_SUCCESS;
}

prints 0.000000  While this:

[spc]lucy:~>lua
Lua 5.1.5  Copyright (C) 1994-2012 Lua.org, PUC-Rio
> print(math.pi)

prints 1.2246063538224e-16 (math.pi is defined as 3.1415926535898 in Lua
5.1.5).  Even odder, when I change the C code to include the constant as
defined in Lua, I get -0.000000.  You may very well get something different
because of, different CPU, different operating system, different compiler,
etc.

  -spc (Floating point is messy)