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.
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.
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.
-- William
--
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
