Opened 9 years ago
Last modified 7 years ago
#14308 needs_work defect
unwanted maxima verbose output
Reported by:  zimmerma  Owned by:  was 

Priority:  minor  Milestone:  sage6.4 
Component:  interfaces  Keywords:  
Cc:  Merged in:  
Authors:  Nils Bruin  Reviewers:  KarlDieter Crisman 
Report Upstream:  N/A  Work issues:  
Branch:  u/nbruin/maxima_verbose_output (Commits, GitHub, GitLab)  Commit:  972427193788bc3f0c61951b063780772d55edfe 
Dependencies:  Stopgaps: 
Description
with Sage 5.7 I get:
sage: a, q, k = var('a, q, k'); assume(q > 1) sage: try: ....: sum(a*q^k, k, 0, infinity) ....: except ValueError: ....: 0 ....: #0: simplify_sum(expr='sum(q^k,k,0,inf)) #1: simplify_sum(expr=a*'sum(q^k,k,0,inf)) 0
Why do I get the #0
and #1
lines?
Paul
PS: this is one of the examples of our book (in french) about Sage at http://sagebook.gforge.inria.fr/, and it makes our doctests fail.
Change History (15)
comment:1 Changed 9 years ago by
comment:2 Changed 8 years ago by
 Milestone changed from sage5.11 to sage5.12
comment:3 Changed 8 years ago by
 Milestone changed from sage6.1 to sage6.2
comment:4 Changed 7 years ago by
 Milestone changed from sage6.2 to sage6.3
comment:5 Changed 7 years ago by
 Milestone changed from sage6.3 to sage6.4
comment:6 Changed 7 years ago by
 Component changed from calculus to interfaces
 Owner changed from burcin to was
 Summary changed from strange debug output to unwanted maxima verbose output
comment:7 Changed 7 years ago by
This is just what maxima does. It prints a bit of a stack backtrace:
(%i1) t(a):= if a = 0 then 1/0 else t(a1); 1 (%o1) t(a) := if a = 0 then  else t(a  1) 0 (%i2) t(10); expt: undefined: 0 to a negative exponent. #0: t(a=0)(stdin line 0) #1: t(a=1)(stdin line 0) #2: t(a=2)(stdin line 0)  an error. To debug this try: debugmode(true);
Apparently we're not turning this off.
comment:8 Changed 7 years ago by
 Branch set to u/nbruin/maxima_verbose_output
comment:9 Changed 7 years ago by
 Commit set to 972427193788bc3f0c61951b063780772d55edfe
 Status changed from new to needs_review
Thanks! that error finally make me find the better routine in maxima to execute maxima code while getting lisp errors rather than maxima's own funny throw/catch signalling. This simplifies code considerably.
for reference: the printing of 3 lines of traceback is hardcoded in merror
(in the file merror.lisp
), just prior to throwing the macsymaquit
. Previously we were just catching that throw, but the traceback would already have been printed. Instead, by using with$error
we make sure we end up in a different branch (by setting errcatch
to T), which ensures merror
will just raise the appropriate error.
New commits:
9724271  trac 14308: use maxima's own lisp routine for running maxima code while producing lisp errors

comment:10 followup: ↓ 11 Changed 7 years ago by
that error finally make me find the better routine in maxima to execute maxima code [...]
great!
Paul
comment:11 in reply to: ↑ 10 ; followup: ↓ 13 Changed 7 years ago by
that error finally make me find the better routine in maxima to execute maxima code [...]
great!
Indeed! Took me a while to figure out what was going on there but I agree this is probably better than printing the backtrace (though see here for some other discussion; we could have just commented that out in a patch). The only downside is that it now talks only about ECL and not Maxima, which may be confusing for some folks. What do you think? Otherwise this is fine, modulo doctests...
sage t src/sage/symbolic/expression.pyx ********************************************************************** File "src/sage/symbolic/expression.pyx", line 9388, in sage.symbolic.expression.Expression.solve Failed example: solve(acot(x),x) TypeError: ECL says: cot: argument 0 isn't in the domain of cot. ********************************************************************** File "src/sage/symbolic/expression.pyx", line 9393, in sage.symbolic.expression.Expression.solve Failed example: solve(acot(x),x,to_poly_solve=True) TypeError: ECL says: cot: argument 0 isn't in the domain of cot. ********************************************************************** 1 item had failures:
This comes from
TESTS: :trac:`7325` (solving inequalities):: sage: (x^2>1).solve(x) [[x < 1], [x > 1]] Catch error message from Maxima:: sage: solve(acot(x),x) [] :: sage: solve(acot(x),x,to_poly_solve=True) []
Amazingly, I personally am responsible for the code that catches this. Now that we have the lib etc., what do you think? I think it's still okay that we catch an error in solve and just return that we can't do it, but in retrospect the way I did it was just enough to get by.
comment:12 Changed 7 years ago by
my opinion is that it is better to get rid of those debug lines from Maxima, that couldn't be caught at all before. Thanks.
Paul
comment:13 in reply to: ↑ 11 Changed 7 years ago by
Replying to kcrisman:
that error finally make me find the better routine in maxima to execute maxima code [...]
great!
The only downside is that it now talks only about ECL and not Maxima, which may be confusing for some folks. What do you think?
I'm not so keen on the ECL says  Maxima says bit. It makes debugging feel like marriage counselling. I only put that in when I was writing the error catching and I wanted to confirm which code was catching/producing the errors. We can of course regain this behaviour quite easily without patching merror or writing the horrible shim we had before. If errcatch is true then merror raises a very clearly marked condition (CL for exception) so we could just catch that and raise another error with the "Maxima says" thrown in. I'd rather stick to what maxima offers already, though.
Amazingly, I personally am responsible for the code that catches this. Now that we have the lib etc., what do you think? I think it's still okay that we catch an error in solve and just return that we can't do it, but in retrospect the way I did it was just enough to get by.
I would normally think it's not a good idea to catch that error so broadly  you really only know *something* went wrong (and having Maxima in the error message hardly improves that  Checking the "ECL" is hardly more generic). On the other hand, it's in solve. Those answers aren't trustworthy if there's no error either.
comment:14 Changed 7 years ago by
On the other hand, it's in solve. Those answers aren't trustworthy if there's no error either.
In this particular case, I guess we noticed that
cot: argument 0 isn't in the domain of cot.
which is true, and so solve should give the empty solution. Would it be fairly easy to change that solve code to catch this type of wording argument 0 isn't in the domain
in which case presumably no solution is correct? Though...
(%i6) solve(x*acot(x),x); cot: argument 0 isn't in the domain of cot. (%i7) acot(0) ; %pi (%o7)  2
which is not ideal. I opened https://sourceforge.net/p/maxima/bugs/2844/ for this.
Anyway, one way or another that doctest failure needs to be dealt with, and so much the better if it improves the solve code.
comment:15 Changed 7 years ago by
 Reviewers set to KarlDieter Crisman
 Status changed from needs_review to needs_work
Anyway, one way or another we need to decide what to do with these doctests.
I get those sometimes too, but I don't recall them making doctests fail... It's some kind of verbose Maxima thing.