On Jan 15, 2010, at 11:14 AM, William Stein wrote:
On Fri, Jan 15, 2010 at 10:16 AM, Robert Bradshaw
<rober...@math.washington.edu> wrote:
On Jan 15, 2010, at 9:58 AM, Craig Citro wrote:
As to Craig's point, yes you can make another Maxima session, but
in
general all internal Maxima use either uses _maxima_(), which calls
the "calculus" copy, or directly uses the "calculus" copy of
Maxima.
For instance for assumptions we really want to only be using one
Maxima session.
Actually, that's not what I was saying. The point that I was making
(too briefly, apparently -- I was typing on my Droid :) ) is that we
already have two default sessions of maxima floating around: one in
sage.interfaces.maxima, which is what a call to maxima() from the
command line uses, and sage.calculus.calculus.maxima, which is what
gets used by the symbolics behind the scenes. So I have two
questions:
1) Do we have two maxima sessions floating around on purpose? That
is,
do we *want* the session we use for symbolic simplification to be a
different session than the one the user has access to from the
command
line? (I could see an argument for doing this, but I'm not clear
as to
whether it was on purpose or by accident.)
I think we do. Maxima sessions can have so much state that it's
nice to keep
them separate to ensure consistency of the calculus modules. Also,
that
means you won't be accidently clobbering your calculus variables,
functions,
etc.
This is definitely on purpose. I made this design decision long ago.
It's for the reason Robert mentions.
2) We start them with different options, which is why maxima("d2")
just returns d2, but sage.calculus.calculus.maxima("d2") returns the
factorial business that started this thread. Do we want to have some
of the options used to start sage.calculus.calculus.maxima also used
in sage.interfaces.maxima?
I also want to point out something that other people may have
realized, but has confused me before: if you're trying to do a
symbolic simplification, and maxima asks you a question, if you do
maxima("assume(x>0)") and try again, it will fail -- because it's
getting sent to the wrong maxima session:
sage: sqrt(x^2)
sqrt(x^2)
sage: sqrt(x^2).simplify()
sqrt(x^2)
sage: maxima.assume("x>0")
[x>0]
sage: sqrt(x^2).simplify()
sqrt(x^2)
sage: sage.calculus.calculus.maxima.assume("x>0")
[x>0]
sage: sqrt(x^2).simplify()
x
Do other people find this confusing?
Eventually (if not already) assumptions and the like will need to be
recorded and used at a higher level than the maxima interpreter
process, so
I don't think we could always count on the above working.
They are already recorded at a higher level -- this has been the case
since 2007.
Yep, I remember working on that during the symbolics switch over. I
don't think we use it much yet though (though there's been a lot of
talk about doing so for the result of the solve command).
sage: sqrt(x^2)
sqrt(x^2)
sage: assume(x>0)
sage: sqrt(x^2)
sqrt(x^2)
Hey wait, WTF?! This is really bad. I don't know what went wrong.
Evidently there is a new bug.
This is because assumptions don't get used until we simplify (or
otherwise make the round-trip to maxima).
sage: sqrt(x^2).simplify()
sqrt(x^2)
sage: assume(x>0)
sage: sqrt(x^2).simplify()
x
Perhaps Pynac could be informed of assumptions as well.
Anyway, regarding the above, Maxima should *never* need to be
explicitly invoked or mentioned for using Sage symbolics. Doing so is
very bad, since it would make is so symbolic user code depends
explicitly on Maxima. That's not good, since someday Sage's symbolics
likely won't use Maxima for any symbolic functionality.
+1
Even if we use Maxima for some stuff for a long time to come (which I
think is the case), it hurts our flexibility to require the end user
to interact with it directly.
- Robert
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
