#12032: Symbolics code passes ungrammatical expressions to maxima
-----------------------------+----------------------------------------------
Reporter: nbruin | Owner: burcin
Type: defect | Status: new
Priority: major | Milestone: sage-5.0
Component: symbolics | Resolution:
Keywords: | Work issues:
Report Upstream: N/A | Reviewers:
Authors: | Merged in:
Dependencies: | Stopgaps:
-----------------------------+----------------------------------------------
Comment (by nbruin):
This bug was rediscovered in [http://groups.google.com/group/sage-
devel/browse_thread/thread/3247c3881c8db6f4?hl=en 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
function:
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 ==
1.58711797464)
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
lines:
...
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
False
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.
}}}
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/12032#comment:1>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
