Ticket #1460 (closed defect: fixed)
[with patch, with positive review] bug in float( ... ) conversion in calculus
|Reported by:||was||Owned by:||was|
On Dec 11, 2007 8:39 AM, Joel B. Mohler <firstname.lastname@example.org> wrote: > > Hi, > > I've noticed a very recent regression -- it worked 2 months ago. > > sage: t=var('t') > sage: f=t*cos(0) > sage: float(f(1)) > 1.0 > sage: f=t*sin(0) > sage: float(f(1)) > Traceback... > <type 'exceptions.TypeError'>: float() argument must be a string or a number > > -- It is actually hard to decide how to fix this. This is a result of several significant fixes and optimizations recently. What is happening is that for t*sin(0) the simplified form is 0, so (t*sin(0)).variables() is . sage: t=var('t') sage: f = t*cos(0) sage: f.variables() (t,) sage: g = t*sin(0) sage: g.variables() () sage: float(f(1)) 1.0 sage: float(g(t=1)) 0.0 Both f(1) and g(1) are formal products. However: sage: g(1)._operands [t, 0] sage: f(1)._operands [1, 1] Notice the [t, 0]. One possible solution would be to call simplify before doing float(...) -- but that could greatly slow symbolic calculus down in some cases. Another possibility would be to change the definition of variables() to return all variables, even the ones that are simplified away: sage: (x - x).variables() # fake (x,) That would be very confusing. A third possibility would be to make implicit calling use variables in the unsimplified expression if the simplified expression has no variables. This would cleanly deal with your case above. Thoughts?
- Summary changed from bug in float( ... ) conversion in calculus to [with patch] bug in float( ... ) conversion in calculus
- Summary changed from [with patch] bug in float( ... ) conversion in calculus to [with patch, with positive review] bug in float( ... ) conversion in calculus
Note: See TracTickets for help on using tickets.