On Nov 13, 2007, at 8:06 PM, Joel B. Mohler wrote: > > On Tue, Nov 13, 2007 at 01:01:47AM +0000, Robert Bradshaw wrote: >> >> This is the issue, which is also the issue with the __richcmp__ >> (you'll need to remove that and __cmp__ to get __hash__ to work). >> >> http://webmaster.iu.edu/tool_guide_info/python/api/type-structs.html >> >> This field is inherited by subtypes together with tp_richcompare and >> tp_hash: a subtypes inherits all three of tp_compare, tp_richcompare, >> and tp_hash when the subtype's tp_compare, tp_richcompare, and >> tp_hash are all NULL. > > Ok, that answers that question, but leaves me with others. If I > comment out the > __richcmp__ implementation of the most specific classes (e.g. > MPolynomial_libsingular), I can hash my mpolys just fine. But, it > breaks other > stuff (x==x+0 is no longer true). > > So, element.pyx has big comment blocks above __richcmp__ and a few > others which > I guess are supposed to explain what is going on here. However, > they leave me > confused. I need to override __richcmp__ with some boilerplate > implementation > if I want to take advantage of <something>, but that <something> is > quite > unclear to me. When am I supposed to override __richcmp__ and when > not? It > seems very bad to not override it for MPolynomial_libsingular, but > Polynomial_dense_mod_n does not override it and appears to work > just fine.
Yes, I think that it is a rather confusing design choice (though I understand the logic.) What I recommend is that you write a cdef generic_hash method in the base polynomial class, and as needed write a __hash__ function that calls that. - Robert --~--~---------~--~----~------------~-------~--~----~ 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/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~----------~----~----~----~------~----~------~--~---
