On Mar 20, 4:12 pm, William Stein <[EMAIL PROTECTED]> wrote:
> On Tuesday 20 March 2007 4:00 pm, Nick Alexander wrote:
>
> > For some reason, google won't let me grab your patch. Anyway,
> > converting to string is not a good idea. Better to hash a tuple of
> > real, imag I think. (Maybe you did this already?)
>
> You have to be really careful, since if a == b,
> then one should strive very hard to have hash(a) == hash(b). Thus, e.g.,
> if a is a real and b is a complex number with real part a and imaginary
> part 0, if you hash the strings then you get equality of the hashes, but
> if you hash the tuple you don't.
Hmm, it seems to me that this has deep implications. When hashing,
one really needs to find the 'minimal representation' of the element.
Suppose I want to hash QQ['x'](1), a constant polynomial. This should
hash to the same thing as QQ(1) and ZZ(1), right? Same with (QQ['x'])
['y'](1), etc. And it gets more convoluted when you have more
interesting extension fields.
And what about quotients -- should Mod(1, 3) hash to the same thing as
ZZ(1)? Should (QQ['x']/x^2+1)(1) hash to the hash of ZZ(1)? Should
(QQ['x']/x^2+1)(x) has to the same thing as CC(I)? (For the record, I
think the last one shouldn't happen, but for no strong reason.)
In some sense, we've worked out the general case with the canonical
coercion code. But this is not the same case: here, we want CC(1) to
hash to RR(1), whereas there is no canonical coercion C to R. There
are some conventions around __call__, maybe those hold the correct
answer.
Before I think more about this, do people agree that there are
problems with the current situation? I am interested to know what
will happen when hashing various elements of finite fields, extensions
of finite fields, padic extensions, etc. Same with lattices of number
fields over QQ and ZZ, and embeddings into CC.
Nick
--~--~---------~--~----~------------~-------~--~----~
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/
-~----------~----~----~----~------~----~------~--~---
