On Dec 12, 2007 1:24 AM, Robert Dodier <robert.dodier at gmail.com> wrote:
> On 12/7/07, Stavros Macrakis <macrakis at alum.mit.edu> wrote:
> > I like the idea of explicit boolean connectives; on the other hand, I find
> > it obscure that Maxima currently doesn't parenthesize them on output....
> Well, the lack of parentheses is to be expected... Here's a modification
> ... which makes Maxima more eager to put in parentheses:
Thanks, that's helpful. I agree that Maxima's current output is
correct; it is simply hard to read.
> > (I'm using x==0 to mean equal(x,0); remember that x=0 is false...)
> It seems like x=0 should be OK, since Maxima understands that in
> input to indicate an equation, and not a Boolean expression ...
This isn't an input issue. Some parts of Maxima (solve) treat "=" as
semantic (mathematical) equality, others (is) treat it as syntactic
equality. I wouldn't mind having "=" uniformly mean mathematical
equality, but that would require reviewing all existing Maxima code.
As for using it in the output of Fourier elimination, that seems a bad
idea, since "is" couldn't be used to test the conditions.
> > > or stuff like foo < x and x < bar could be turned into interval objects,
> > > x = 0 or x in open_interval (0, 6/11) or ...
> > Until we have a functional interval package...I don't see the point of this.
>
> Well, at present open_interval or any notation like that is speculative,
> but it seems useful to talk about how that could work.
That's a different matter from starting to use it as the output of
functions today.
> Compared to some of the known tasks (fixing the limit code, etc)
> inventing a new kind of object is much simpler.
???!!! Yes, adding a new kind of object is trivial. Making it work
reasonably in all parts of Maxima is not, as witness the many kinds of
object which are not treated properly: bfloats don't work everywhere
floats work; many nounforms (limit, diff, realpart) aren't handled
correctly by other parts of the system; few parts of the system
understand lambda; etc. etc.
Adding a new object requires looking at *all* the rest of the system,
while fixing problems in limit, though hard, is at least localized,
and Dan Gildea has been making nice progress on it.
> > > Or maybe the result should be a set?
> What I'm getting at here is that instead of a list of equations or
> inequalities, the result should be a set, since order doesn't matter.
Operators like 'and' and 'or' are commutative and order doesn't matter
there, either. As for sets, again, we don't have simplifying set
operations like union etc. They would be nice to have, and Barton and
I have started working on them, but they're not there yet, especially
not for sets defined by predicates e.g. {x in Real | x>0}.
-s