MOO-cows Mailing List Archive


Re: floating point support (was Re: suspend())

hpa writes:

>In article <SPAM> Roger Crew  <> wrote:

[floating point in MOO]

>> Whatever you do, please do *NOT* put in implicit coercions.  
>> For example, in


> I disagree.  I think implicit promotions are very useful.

Some of us prefer to refer to implicit promotion as "floating point
contagion"; the fear is that inexact numbers (in the Scheme sense)
will propagate through the system until eventually, an indeterminate
amount of time later, you get an inexact number where you must have an
exact one, and the system falls down, with no indication of where the
original source of error was.  In a persistent system like MOO, this
is especially frightening.

Not quite as bad is the possibility that you'll end up doing floating
point math on integers much of the time since all it takes is one
float like 1.0 somewhere in the computation to infect the remainder of
operations.  (If you're using single-precision you're in far worse
shape---you can't represent numbers close to $maxint, which does seem
to come up from time to time.)

Also, I think there is a lot of MOO code around that depends on the
fact that there aren't/weren't any numbers between 0 and 1, for
example.  I could swear I've seen (x > 0) and (x >= 1)
interchangeably.  We should be very careful.

> Implicit *demotions* are not.  

I guess after playing with floats a lot I object to the
"promote/demote" terminology as applied to float/fixed conversions.

> % is a perfectly sensible operation on floats
> (returning a floating-point number, e.g. 5.5 % 3 == 2.5).

I suppose that's not so awful as long as the signatures of % are
limited to %(int, int) and %(float, float).

Jay Carlson

Flat text is just *never* what you want.   ---stephen p spackman


Home | Subject Index | Thread Index