On Mar 20, 2007, at 10:27 PM, David Harvey wrote: > On Mar 21, 2007, at 1:19 AM, Nick Alexander wrote: > >> 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. > > Oh boy I really really don't like where this is going. Insisting on > "a == b" => "hash(a) == hash(b)" with sage's canonical coercion model > seems really really bad. > > For example > > sage: Integers(123818273)(2394) == Integers(1)(0) > True > > So then all integers mod n (for all n) have to hash to the same thing. > > Please let's not go there.
There's also the issue of precision, e.g. RDF(0) == RealField(10000) (1), but sage: R = RealField(10000) sage: a = R(1) + R(10)^-100 sage: a == RDF(1) but I don't think hash(a) should equal (necessarily) hash(1). If it seems natural (e.g. in this case where the coercion is R -> C), however, I think it would be nice. One could also force all keys of a hashtable to live in a given ring. - 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~----------~----~----~----~------~----~------~--~---
