On Wednesday 07 November 2007 10:42, Martin Albrecht wrote: > > Sorry to reply to myself when I should have done my research beforehand. > > The issue is that multivariate polynomials over ZZ override hash and hash > > the tuple of tuples of exponents (roughly speaking). This is in stark > > contrast to the default implementation that hashes the string > > representation of an object. Thus, the hashes of mpolys over ZZ hash > > entirely differently than the fractionfield of mpolys over ZZ and hence > > the hashes are not equal. > > Hashing the string representation of self is a nice quick way to implement > hashing but it is definitely quite inefficient however you want to look at > it. I think writing more clever hashing functions is the right way to go. > Also, Python internally doesn't hash string representations.
I noticed that you called the singular p_String method in the hash function of the libsingular mpoly code. This pushes the string code down in to singular (and hence C) which is presumably *much* faster than some of the tricks we play in other poly __str__ methods. Was this "more clever" in your opinion? I'm not speaking for or against it, I'm just trying to get a better feel for what you are advocating. Hashing string is definitely one of the easiest ways to get a lot of semantics that we want ... i.e. agreement with '=='. In all other respects, it seems like one of the most awful hash algorithms one could imagine. However, I'm not saying it's a bad design decision since agreement with '==' is pretty much the central requirement. It does mean that using dictionaries with SAGE types has entirely different run-time characteristics than one might expect with dictionaries (although I think some actual benchmarks would be appropriate to support that claim and I plan to look into that a bit myself). -- Joel --~--~---------~--~----~------------~-------~--~----~ 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~----------~----~----~----~------~----~------~--~---
