Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmp for number field elements #6132

Closed
robertwb opened this issue May 26, 2009 · 10 comments
Closed

cmp for number field elements #6132

robertwb opened this issue May 26, 2009 · 10 comments

Comments

@robertwb
Copy link
Contributor

See discussion at http://groups.google.com/group/sage-nt/browse_thread/thread/422606e40805d5d0?hl=en

Note that cmp(list(a), list(b)) can be slow...

Component: basic arithmetic

Issue created by migration from https://trac.sagemath.org/ticket/6132

@rlmill
Copy link
Mannequin

rlmill mannequin commented May 26, 2009

comment:1

Minor, but I just fixed two of these elsewhere: it's spelled "consistent"

@robertwb
Copy link
Contributor Author

Attachment: 6132-nf-elt-cmp.patch.gz

@aghitza
Copy link
Contributor

aghitza commented May 30, 2009

comment:3

The patch applies with some fuzz to 4.0.rc2, but I'm seeing a bunch of doctest failures in sage/rings:

The following tests failed:


	sage -t  "devel/sage-main/sage/rings/number_field/number_field.py"
	sage -t  "devel/sage-main/sage/rings/number_field/number_field_rel.py"
	sage -t  "devel/sage-main/sage/rings/number_field/order.py"
	sage -t  "devel/sage-main/sage/rings/number_field/galois_group.py"
	sage -t  "devel/sage-main/sage/rings/number_field/number_field_element.pyx"
	sage -t  "devel/sage-main/sage/rings/number_field/number_field_ideal.py"
	sage -t  "devel/sage-main/sage/rings/number_field/number_field_ideal_rel.py"
	sage -t  "devel/sage-main/sage/rings/number_field/unit_group.py"
	sage -t  "devel/sage-main/sage/rings/polynomial/complex_roots.py"
	sage -t  "devel/sage-main/sage/rings/polynomial/polynomial_element.pyx"

@nbruin
Copy link
Contributor

nbruin commented Jan 28, 2010

comment:4

In Python 3, "greater than" etc. comparisons between objects where no natural ordering exist are supposed to raise a "TypeError"

Already, comparing complex numbers in Python 2.6.2 raises
TypeError: no ordering relation is defined for complex numbers

Changing this will probably lead to even more doctest failures, but brings us closer to Python's way of doing things and to mathematical sanity.

@nbruin nbruin assigned nbruin and unassigned nbruin Jan 28, 2010
@robertwb
Copy link
Contributor Author

comment:6

Note that to follow this convention, we have to use __richcmp__ as == and != should still work for unordered elements.

@kcrisman
Copy link
Member

kcrisman commented Feb 7, 2011

comment:7

Apparently related to #7160 and #10064, see this sage-devel discussion.

@williamstein
Copy link
Contributor

comment:8

See also #9572.

@kcrisman
Copy link
Member

comment:9

Replying to @williamstein:

See also #9572.

That is a SageNB release ticket. ?

@williamstein
Copy link
Contributor

comment:10

See #7160 for a related ticket/discussion.

@mwhansen
Copy link
Contributor

comment:11

I think we can close this as a duplicate of those other tickets now that they are merged.

@mwhansen mwhansen removed this from the sage-5.11 milestone Jul 22, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants