Re: *Very* alpha MOO floating-point patch

• Date: Mon, 22 Jan 1996 12:31:08 PST
• From:
  ThwartedEfforts <abakun@scinc.com>
• Content-Type: text/plain; charset="us-ascii"

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

• Prev: Re: $string_utils:explode()
• Next: Re: *Very* alpha MOO floating-point patch
• Index: MOO-cows
• Thread: MOO-cows