Nils Bruin <nbr...@sfu.ca> writes: >> ... >> si = numpy.sign(xm-xf) + ((xm-xf)==0) >> ... >> si = numpy.sign(rat) + (rat == 0) >> x = xf + si*max([abs(rat), tol1]) >> ... > > Ah shoot. That code is quite understandable. 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.
Would replacing that code with your code be detrimental to scipy? Why not submit a pull request? I submitted a "please be more robust in this weird corner case so that Sage doesn't break you with its custom objects" type pull request to simplejson [1], for example, and it was kindly accepted by the maintainer. Maybe the same would happen with scipy. In any case, one could also argue that implicitly casting bools to integers is not very Pythonic, if one were feeling a bit impish :P Then again maybe there are some performance-related reasons, invisible to me, for the way the code is. -Keshav [1]: http://github.com/simplejson/simplejson/pull/29/files -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
