>> I think common subexpressions should be (loosely) checked for >> equality, *not* restricting to the same Python instance only. > > Hmm... this is a tradeoff between speed in constructing the > fast_callable and speed in using it. Do other people think that > common subexpressions are likely?
In my mind, the whole point of a fast_callable object is to gain calling speed via more one-time investment. I don't think we should do a whole simplification routine by default, but a very simple equality checking could be done in negligible time (e.g. it would only compare the actual expression tree structure, not for algebraic equivalence, except perhaps in some cases taking advantage of the commutativity of some binary operations). >> The question of unpickling old fast_float objects has come up. These >> may have gotten attached to pickled symbolic expressions or >> polynomials, so should be unpicklable. However, if one writes a >> compatible _unpickle_FastDoubleFunc then one doesn't need to care >> they whole old implementation around. > > I can't find any caching for fast_float objects (I can't see anywhere > they would get attached to a symbolic expression or a polynomial). Am > I just not looking in the right place? Compiled polynomials get attached to polynomial objects, but if you're not seeing fast floats getting stuck into dictionaries and the like then we're probably lucky and I doubt there's (m)any pickled versions of them floating around. - Robert --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
