Opened 10 years ago

Last modified 7 years ago

#12032 new defect

Symbolics code passes ungrammatical expressions to maxima

Reported by: nbruin Owned by: burcin
Priority: major Milestone: sage-6.4
Component: symbolics Keywords:
Cc: Merged in:
Authors: Reviewers:
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Status badges


Eviatar reports sage-devel thread:

sage: find_maximum_on_interval(-x^2 + 9*x, 4.4, 8)
RuntimeError: ECL says: THROW: The catch MACSYMA-QUIT is undefined.

A little investigation with shows that the error occurs in sage.interfaces.maxima_lib line 420

if statement: result = ((result + '\n') if result else '') + max_to_string(maxima_eval("#$%s$"%statement))

where statement has the value

'is (-20.247454751128636=-20.249999999999996<=-20.199549540424666)'

which is not a valid Maxima expression. The real error is in the code that causes this to happen.

The function maxima_eval is an ECL function, so its parameter gets converted by ECL-lib, outside maxima_lib's control. The string contains a #$...$ reader-macro, which causes the maxima-parser to handle the string. It finds the syntax error and signals it by throwing an uncaught "catch".

Invoking maxima_eval this way isn't particularly wrong, but one should ensure that the expression passed in is at least syntactically correct. If an error condition arises when *evaluating* the expression using maxima_eval, errors are caught more gracefully.

Digging a little deeper shows that find_maximum should not be called with symbolic arguments, so this particular error could be caught earlier. However, I think the symptom shows that the symbolics code should vet its expression a little better before passing it to maxima: The expression isn't accepted by maxima as grammatical.

Change History (5)

comment:1 Changed 9 years ago by nbruin

This bug was rediscovered in this sage-devel thread. A little further debugging uncovered some further details there:

Yes, that's a bug. Something goes wrong in what gets fed to the

def f(z):
    v = sin(x)(x=z)
    print "evaluating sin(%s)=%s"%(z,v)
    return vsage: find_maximum_on_interval(f,0,2)
evaluating sin(0.7639320225)=0.691766183638
evaluating sin(1.2360679775)=0.944499585162
evaluating sin(1.527864045)=0.999078551136
evaluating sin(1.59062900282 == 1.58711797464)=sin(1.59062900282 ==

As you see, for some reason the evaluation point becomes an equality
relation. From that point it is of course just a question *which*
piece of code throws an error.

These routines use scipy.optimize.fminbound. This doesn't act too
nicely with the SymbolicRing. In the source, we find the following

                    si = numpy.sign(xm-xf) + ((xm-xf)==0)
        si = numpy.sign(rat) + (rat == 0)
        x = xf + si*max([abs(rat), tol1])

 What they need is:

        si = numpy.sign(xm-xf)
        if si == 0:
            si = 1
    si = numpy.sign(rat)
    if si == 0:
       si = 1
    x = xf + si*max([abs(rat), tol1])

Their assumption that numpy.sign(rat) == 0 iff (rat == 0) evaluates to
1 and that (rat == 0) evaluates to 0 otherwise is not unreasonable in
their world. The above code is of course a little more robust, but I
doubt scipy is willing to change it just because sage's SR acts funny.
So the fix: sage should interface a little more carefully with scipy
and take care no SR objects leak into it. 

The problem comes from the fact that the symbolic ring is
quite conservative in deciding whether floats are equal to zero and
has the habit of returning something that is not readily 0 or 1:

sage: 1.1 == 0
sage: SR(1.1) == 0
1.10000000000000 == 0

So at the least, the sage interface prepares input to scipy that
doesn't behave as scipy expects. It may also be that the scipy
implementation is suspect.

The nasty error comes from the fact that the syntactically invalid
expression sin(1.59062900282 == 1.58711797464) doesn't get rejected
upon construction.

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
Note: See TracTickets for help on using tickets.