# *Very* alpha MOO floating-point patch

ThwartedEfforts (abakun@scinc.com)
Mon, 22 Jan 1996 12:31:08 PST

- Messages sorted by:[ date ][ thread ][ subject ][ author ]

    At 08:35 PM 1/20/96 PST, H. Peter Anvin <hpa@trantor.storm.net> wrote:
    >I have put a *very* alpha MOO floating-point math patch on
    ><ftp://ftp.storm.net/pub/fpmoo.diff.gz>.  This is a patch against
    >Pavel's LambdaMOO-1.8.0alpha6 release from parcftp.xerox.com.  This
    >patch implements floating-point math as a new atomic data type.

    It's very neat.

    -rw-r--r--   1 900      100         20401 Jan 21 15:05 fpmoo.diff.gz
    -rw-r--r--   1 900      100         19977 Jan 22 01:47 fpmoo2.diff.gz

    I grabbed fpmoo2.diff.gz, since that one had a later date, so I figured it
    was 'more current', even with the slightly smaller size.

    >IMPORTANT: The version of autoconf I have on my system is incompatible
    >with the configure.in file.  Therefore, the "configure" script is not
    >patched correctly.  After running "configure", you have to manually
    >edit config.h to set the correct value for the HAVE_ISNAN config
    >variable (on most modern system, HAVE_ISNAN should be #define'd.  If
    >you are unsure, #define it; you will get a compile error if it is
    >#define'd when it should not be.)

    The linux 1.2.13 (slackware 3.0, I believe) that I'm using to compile this
    on couldn't find 'autoconf', and make wouldn't execute without it, so I make
    ./autoconf as a shell script that did nothing, which got it past that part
    of the making process.

    Under linux tho, I did have to define HAVE_ISNAN, since math.h defined it.
    After that, clean compiliation, as usual :)

    >The following math functions are supported in this patch: sin, cos,
    >tan, atan, asin, acos, sinh, cosh, tanh, atanh, asinh, acosh, exp,
    >log, ceil, floor, int, sqrt, abs.  sqrt and abs return integer type if the
    >argument is an integer type, the others always return type FLOAT.
    >atan() and log() can take either one or two arguments (atan(x,y)
    >computes the four-quadrant equivalent of atan(y/x); log(a,b) computes
    >log base b of a).

    I tested a few of these, they work like they are susposed to (I guess, I
    didn't calculate them by hand to check them :) ).

    >A new operator ^ supports exponentiation.  Currently it returns FLOAT
    >at all times, that might change however.

    Works. (except for the existance of FLOAT, which I explain below)

    >NUM and tonum() have new aliases INT and toint().
    >A new function tofloat() converts any type to FLOAT.

    toint() works (didn't test the others). INT doesn't exist.
    typeof(3.3) == 0 == NUM ??
    Looking at the code, you should probally add SLOT_FLOAT sym_table.h, add it
    to the runtime env in eval_env.c, and such, etc, so that FLOAT is a new
    builtin variable.  Of course, if you fully intend to treat integers and
    floats the same (ie, both being the same MOO type according to typeof(),
    then no problem), but I was under the impression (from the sentences I
    quoted above) that FLOAT was a new type, in as much as OBJ and LIST are types.

    >A new function const() can be used to obtain the values for some
    >commonly used floating point constants.

    Doesn't exist.  I assume the correct usage would be something like
    const("e") or const("pi")?

    >A new error E_MATH (Error in floating-point math) has been
    >introduced.  It applies to both overflow and domain errors.

    ;sqrt(-1) return E_MATH, and tostr(E_MATH) works.
    Note that certain code in the db, like $error, needs to be changed to
    reflect the addition of this new error code, but that's a minor issue.

    Of course, this is all alpha, so any problems are understandable.

    Keep us updated, please, this is all very interesting.

    Andy
    ThwartedEfforts