On Wednesday 07 November 2007, Joel B. Mohler wrote: > 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?
Actually, no. I was just being lazy. It should loop over the terms and compute the hash directly. Off course this should be done in C. http://effbot.org/zone/python-hash.htm has an overview of Python's built-in hashes and I would say polynomials should be hashed like tuples there. > 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. Is it? Is this written down somewhere? It is just that I hear the first time about this requirement in this thread. I usually aimed for speed and small chance of clashes first. Martin -- name: Martin Albrecht _pgp: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8EF0DC99 _www: http://www.informatik.uni-bremen.de/~malb _jab: [EMAIL PROTECTED] --~--~---------~--~----~------------~-------~--~----~ 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/ -~----------~----~----~----~------~----~------~--~---
