On Fri, Jan 15, 2010 at 11:07 AM, Craig Citro <craigci...@gmail.com> wrote:
>> 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.
>>
>
> I think I agree in principle, but maybe not in practice. For the user
> who knows nothing about Maxima, they're definitely not going to try to
> do anything via maxima("...") themselves, so I think it doesn't matter
> for them. On the other hand, our use of Maxima clearly isn't perfect
> -- if someone knows enough about Maxima to be able to fix the problem
> they're having on the Maxima side, it would be nice if that were a
> little easier. Since integrate() and friends often comes back with an
> error message talking about what we need to tell Maxima first, it'd be
> nice if it were easier to do that. I guess I'm saying that I think the
> benefits outweigh the dangers -- someone making calls via
> maxima("...") probably realizes the prospect of clobbering variables,
> unless maybe they were just copy-pasting someone else's code that does
> it.
I disagree. This would lead to people writing code that will just
break later as Sage symbolic stop depending on Maxima (this dependence
is a temporary thing, IMHO).
>
>> 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.
>>
>
> I agree -- ultimately the user should never need to know that we're
> using Maxima, and in theory we could one day be using some completely
> different backend for integrals. But right now, lots of integrals end
> in tracebacks like this:
>
> TypeError: Computation failed since Maxima requested additional
> constraints (try the command 'assume(sin(x+%pi/3)>0)' before integral
> or limit evaluation, for example):
> Is sin(x+%pi/3) positive, negative, or zero?
>
> Using assume or maxima.assume doesn't help, but using
If that is true (is it?), that's just a big bug. It did help until
very recently.
> sage.calculus.calculus.maxima.assume *does* fix it. I just tested, and
> the first three problems on sage-support about maxima and assume I
> looked at were all fixed by using sage.calculus.calculus.maxima.assume
> instead. I agree that it's not the solution we want in the long term,
> but either (1) unifying the two maxima sessions or
No.
> (2) making the
> assume() command available at top-level point to
> sage.calculus.calculus.maxima.assume *would* make it so that the user
> could easily compute the integral that's frustrating them.
Again, (2) *was* the case since the beginning, and if it isn't now, it
is because somebody screwed stuff up and introduced a *huge* bug into
Sage recently.
> (I know
> that the one time I've run into this, I tried an integral, got a
> traceback about assume, tried maxima("assume(...)"), which didn't fix
> it -- so I gave up and just did the integral by hand.)
>
> -cc
>
> --
> 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
>
>
--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org
--
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
