#20028: sorting of number field elements
-------------------------------------+-------------------------------------
Reporter: cremona | Owner:
Type: defect | Status: new
Priority: major | Milestone: sage-7.1
Component: number fields | Resolution:
Keywords: sort number field | Merged in:
elements | Reviewers:
Authors: | Work issues:
Report Upstream: N/A | Commit:
Branch: u/cremona/20028 | ae87261971f6ddc93d1d40c24c3a141be58457bd
Dependencies: | Stopgaps:
-------------------------------------+-------------------------------------
Comment (by nbruin):
Replying to [comment:28 cremona]:
> Nils, can you explain the following?
>...
> then there are many failures, for example
> {{{
> sage: pol26 = hilbert_class_polynomial(-4*26)
> sage: K = NumberField(pol26,'a')
> sage: K.optimized_representation()
> <boom>
> NotImplementedError: root finding for this polynomial not implemented
> }}}
I am not quite sure what you mean by "explain". Do you want me to give my
interpretation of the traceback that shows where the failure occurs? In
that case:
The error happens in `sage.rings.polynomial.polynomial_element.pyx:6533`,
in `Polynomial.roots`. The relevant branches are:
{{{
try:
if K.is_integral_domain():
...
return self._roots_from_factorization(self.factor(),
multiplicities)
else:
raise NotImplementedError
except NotImplementedError:
...
raise NotImplementedError("root finding for this polynomial
not implemented")
}}}
With the change, "self.factor()" indirectly raises `NotImplementedError`
from the `sort`. The really appropriate solution would be to just not sort
in `self.factor` at all, because in general there's no way to sort. But I
suspect the number of doctests that need to be adjusted would be very
unpleasant. So I'd go with the "best effort sorting attempt" of a `try`
here.
You can see two things here:
- Python's try/except invites a rather coarse-grained error selection
here. Python advocates EAFP over LBYL (ask forgiveness rather than look
before you leap) and it has advantages in systems programming, where error
conditions can be transient, but I think it's a poor match for mathematics
programming, exactly for this kind of poorly matched interactions.
- If you raise an error in an except, you should use a bare `raise`
unless you have a very good reason not to. Getting the original error here
is way more informative (and cheaper!) than this newly constructed error.
--
Ticket URL: <http://trac.sagemath.org/ticket/20028#comment:30>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
