[Maxima-bugs] [ maxima-Bugs-902694 ] equal(ind,ind) should be false; also und, NaN

[SourceForge.net <no...@so...>]

Bugs item #902694, was opened at 2004-02-23 06:58
Message generated for change (Comment added) made by robert_dodier
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=104933&aid=902694&group_id=4933

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: Lisp Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Stavros Macrakis (macrakis)
Assigned to: Nobody/Anonymous (nobody)
Summary: equal(ind,ind) should be false; also und, NaN

Initial Comment:
is(ind=ind) => true  OK, is/= is syntactic
is(equal(ind,ind)) => true NO! is/equal should be semantic

Unlike IEEE floating point, Maxima carefully
distinguishes syntactic and semantic equality tests. 
Clearly everything, including ind / und / IEEE_NaN, is
syntactically equal to itself.

However, not everything is semantically equal to
itself.  In particular, equal(und,und), equal(ind,ind),
and equal(IEEE_NaN, IEEE_NaN) (when we support it)
should be false.


----------------------------------------------------------------------

>Comment By: Robert Dodier (robert_dodier)
Date: 2006-07-23 12:54

Message:
Logged In: YES 
user_id=501686

Observed in 5.9.3cvs.

Incidentally I'm not convinced these are errors. A useful
definition of Maxima equal(a,b) is that substituting a for b
in any expression yields an equivalent expression. Certainly
when a and b are the same symbol, that's true. 

To forestall two criticisms which I can see coming: 

(1) ratsimp(a - b) = 0 might be suggested as an alternate
definition of equal(a,b). That's too narrow, as there are
interesting expressions for which a - b isn't defined. E.g.
a is a set and b is a matrix.

(2) equal(a,a) => true for all symbols a isn't consistent
with IEEE floating point. Well, I've given up on IEEE
floating point special values in Maxima because Common Lisp
doesn't require them, and some implementations (Clisp, GCL
at least) don't support them. 


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=104933&aid=902694&group_id=4933