2009/5/22 John Cremona <john.c...@gmail.com
> 2009/5/22 N. Bruin <nbr...@sfu.ca
>> On May 22, 4:23 am, John Cremona <john.crem...@gmail.com
>>> Elements of number fields currently have no custom cmp() function
>>> which means that x>y is always True and x<y is always False when x!=y.
>>> We need to be able to sort lists of number field elements properly,
>>> which requires implementing this.
>> Do we? Unlikely comparisons have been discussed before. Python 3.0
>> returns TypeErrors on many comparisons, e.g. Python complex numbers do
>> not allow comparison. Hence, I don't think there is any pressure from
>> the language environment in sage to make all objects comparable. There
>> is not a very good mathematical reason to do it either, unless you
>> are considering a special class of number fields with a fixed real
> I am not thinking about a mathematically sensible sorting, i.e. not a
> partial order in the mathematical sense. I actually want sorted lists
> for implementing modular symbols where it is important to be able to
> look things up quickly.
> If that can be done (deterministically and fast) some other way, I
> would be happy.
Some notes: In sage-3.4.2, number field elements do not even have a
sensible hash -- it is just some default hash inherited from Element
(?), which is "hash of the string representation". If you fix this by
defining __hash__ (which I expect you did), then because of how Cython
works, the cmp code will be deactivated unless one explicitly defines
__richcmp__. Anyways, in sage-4.0.rc0, number field elements *do*
have a proper hash function (=the hash of the defining polynomial),
since I had to implement this as part of the Pynac switch.
>> To get the effect you are describing above (roughly), one could do
> That is neat; my python knowledge has just expanded a bit!
>> which is both short and requires people to acknowledge that they are
>> making a (necessary) choice about how L is supposed to be sorted. I
>> would think explicit is better than implicit for this too.
>> Is the main reason to force things like roots to produce deterministic
>> output to facilitate doctesting? Would it be bad to put the sort
>> command in the doctest?
> That is very sneaky!
Associate Professor of Mathematics
University of Washington