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: sage-6.4
Component: interfaces Keywords:
Cc: Merged in:
Authors: Nils Bruin Reviewers: Karl-Dieter Crisman
Report Upstream: N/A Work issues:
Branch: u/nbruin/maxima_verbose_output (Commits, GitHub, GitLab) Commit: 972427193788bc3f0c61951b063780772d55edfe
Dependencies: Stopgaps:

Status badges

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 kcrisman

I get those sometimes too, but I don't recall them making doctests fail... It's some kind of verbose Maxima thing.

comment:2 Changed 8 years ago by jdemeyer

  • Milestone changed from sage-5.11 to sage-5.12

comment:3 Changed 8 years ago by vbraun_spam

  • Milestone changed from sage-6.1 to sage-6.2

comment:4 Changed 7 years ago by vbraun_spam

  • Milestone changed from sage-6.2 to sage-6.3

comment:5 Changed 7 years ago by vbraun_spam

  • Milestone changed from sage-6.3 to sage-6.4

comment:6 Changed 7 years ago by kcrisman

  • 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 nbruin

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(a-1);
                                           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 nbruin

  • Branch set to u/nbruin/maxima_verbose_output

comment:9 Changed 7 years ago by nbruin

  • Authors set to Nils Bruin
  • 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 macsyma-quit. 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:

9724271trac 14308: use maxima's own lisp routine for running maxima code while producing lisp errors

comment:10 follow-up: Changed 7 years ago by zimmerma

that error finally make me find the better routine in maxima to execute maxima code [...]

great!

Paul

comment:11 in reply to: ↑ 10 ; follow-up: Changed 7 years ago by kcrisman

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 zimmerma

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 nbruin

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 kcrisman

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 kcrisman

  • Reviewers set to Karl-Dieter Crisman
  • Status changed from needs_review to needs_work

Anyway, one way or another we need to decide what to do with these doctests.

Note: See TracTickets for help on using tickets.