Stavros Macrakis wrote:
> On Sun, Jun 6, 2010 at 15:21, R Fateman <fateman at cs.berkeley.edu
> <mailto:fateman at cs.berkeley.edu>> wrote:
>
> ...now consider (setf n '((mbox simp)((mplus simp) $a $b)))
> (setf m (cadr n))
> ...
> (great n m) is T
> (great m n) is also T
>
> this is apparently not an error, or at least it works the same in
> 5.17 maxima and 5.21 maxima.
> the ordering of some expression E and box(E) should be the
> same...
>
>
> Though undoubtedly (X<E iff X<box(E)) and (E<X iff box(E)<X) when X is
> not a box-expression, that does not mean that E<box(E) and box(E)<E
> should both be TRUE. If they are, the canonical (simplified) form of
> (e.g.) x+box(x) is not well-defined.
yep.
> I would guess that there are other parts of Maxima besides simp-%sin
> that can break if E<box(E) and box(E)<E.
except that it seems the system works with an older simp-%sin...
I agree in principle with Stavros. but maybe then (alike E ((mbox )
E) should return T.
Here is a thought, which I think I've expressed previously,
that having great() check for mbox so much is uncomfortable, since it
almost never is there.
maybe we can move this out of the main loop of the simplifier (i.e. in
great or in alike).
One possibility is to put the "box" info somewhere else, not exactly in
the expression tree.
e.g. ((mplus simp BOX BOXLABEL) $a $b).
So this could be noticed by the display program, but ignored by great().
Hazards: what to do with just a symbol, e.g. $A. ((mplus simp
BOX BOXLABEL) $A 0) ???
Also ((mplus) $X ((mplus simp BOX) $X $Y) ) would try to make
2*x+y... where's the box?
Back to work..
RJF