On Jun 22, 2012, at 2:12 AM, Joachim Durchholz <[email protected]> wrote:
>>>> The problem I do see is that it's inherently recursive, meaning we are >>>> limited by the Python stack (unless we do it with a manual stack). >>>> Actually, it seems that hash() itself works regardless of this fact, >>>> which is interesting. If I create a highly nested expression, one >>>> where I know that recursively calling hashable_content() will overflow >>>> the stack, I can still hash it. >>> >>> Does the hash code depend on the subexpressions? >>> (x+(y+z)) should have a different hash code than (x+(y+a)), for example. >> >> Yes, but that's not exactly sub-expressions. x + y + z is denested >> into Add(x, y, z). > > Lol okay :-) > > > A better example would be x + y*z, which is Add(x, >> Mul(y, z)). > > Okay... then make sure that the hash isn't recomputed for each level of > nesting, else you'll get quadratic slowdown with number of nesting levels. If it's the same object, the hash is only computed once, and then hashed. If the object is being rebuilt, it could be an issue. > > Oh. And hash codes must not be changed once they have been computed, that's > what Python wants. > BTW what's the typical pattern in Python to make sure that no hash-relevant > attributes are modified? If an attribute is private (starts with _), then it's a signal to other code that if you use it or modify it, bad things could happen. You can also enforce it using __setattr__ if you're really worried about it. Aaron Meurer -- You received this message because you are subscribed to the Google Groups "sympy" 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/sympy?hl=en.
