Re: +-Inf and NaN

Maxima's box function would, I think, work well for this purpose:


(%i2) x1 : box(inf, gensym());
(%o2) inf

(%i3) x2 : box(inf, gensym());
(%o3) inf

(%i4) x1-x1;
(%o4) 0

(%i5) x1-x2;
(%o5) inf-inf

(%i6) rembox(%);
(%o6) 0

I'd say that the first step would be to find every extended real (minf, zerob, zeroa, ind, inf, and infinity) in the source code and surround it with a box.  It would be easy to miss a few, but it's doable.

A second step would be to look for every place the code looks for equality (either with eq, alike or ?) with an extended real and decide what to do—I think every case would need to be examined.

Third, I think some of the simplification functions for arithmetic (simplus, ...) might need to be modified.  Maybe we would need to make a decision about how to simplify

  box(ind, 42) + box(inf, 107) --> nounform or box(inf, gensym()), or something else?

And if somebody got this far, I'd guess that there will be a fair number of testsuite failures that need to be fixed.

Questions:  Does any computer algebra system use such "uniquified" extended real numbers?

--Barton
________________________________
From: Richard Fateman <[email protected]>
Sent: Friday, February 23, 2024 19:46
To: Stavros Macrakis <[email protected]>
Cc: Robert Dodier <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>
Subject: Re: [Maxima-discuss] +-Inf and NaN

Caution: Non-NU Email

Since Maxima has symbols that are not float NaNs for  inf, minf, infinity, undefined, indefinite...
it would seem superficially plausible to  unite these notations.
Not easy.
For solving inf-inf --> not zero, i've proposed and partially implemented the idea
that inf, as well as und,  should be indexed each time it is generated. Thus
x: 1/0  returns und[1].
y: 1/0  returns und[2]

x-x returns 0.
x-y  is und[1]-und[2]  --> und[3].

how to implement?  lots of patches.
Here's another: allow rational numbers 1/0  and 0/0  and maybe -1/0


On Fri, Feb 23, 2024 at 11:05 AM Stavros Macrakis <[email protected]<mailto:[email protected]>> wrote:
On Fri, Feb 23, 2024 at 12:20 PM Henry Baker <[email protected]<mailto:[email protected]>> wrote:

...There was a reason why Maclisp used a separate function name for float

arithmetic functions, and it wasn't just to speed up float arithmetic.

Actually, that was precisely why. (plus a b) was be translated to (+$ a b) if a and b were of type float.


The real reason is that *floats don't adhere to standard algebraic axioms*.

Well, since plus invokes floating point operations, it has the same issues.


In particular, standard "=" needs to be an *equivalence relation*, which

means transitivity, among other things, so floating point needs its own

brain-damaged 'equality' predicate -- perhaps IEEE-=

Extending data types with an NA value is pretty standard and useful, and not just for floats. One of these days (ha ha), we'll even get Maxima to realize that INF-INF does not equal 0, and that not all INFs are equal.

_______________________________________________
Maxima-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/maxima-discuss