#6079: [with patch, needs review] modernize base inclusion morphism of relative
number fields
---------------------------+------------------------------------------------
Reporter: ncalexan | Owner: was
Type: enhancement | Status: new
Priority: major | Milestone: sage-4.0.1
Component: number theory | Keywords: base inclusion morphism relative
number field
---------------------------+------------------------------------------------
Comment(by ncalexan):
> I found the doctests for this function rather too technical, and too
long
> (in `number_field.py` only `NumberField` and `composite_fields` have
longer
> doctests). A user who'd not used this function would suffer information
> overload (129 lines of doctest). In particular, I don't understand the
> first example at all. What is the section `n` doing there?
I love that you're reviewing this and obviously putting in a lot of time
-- thank you -- but it's as if you're not reading what's written. The
docstring explicitly says that if you're looking for the functionality
that you want to reduce this function to, that section is how to get it.
And then it shows you what the differences are, including how the error
message is more to your liking!
{{{
If you want a map that takes elements of ``self`` and returns elements
4285 of a subfield, try the following:
4286
4287 EXAMPLES::
4288
4289 sage: K.<a, b> = NumberField([x^3 + x + 1, x^2
+ 100])
4290 sage: m = K.coerce_map_from(K.base_field()); n
= m.section(); n
4291 Projection onto base field map:
4292 From: Number Field in a with defining
polynomial x^3 + x + 1 over its base field
4293 To: Number Field in b with defining
polynomial x^2 + 100
4294 sage: m(a^3 + a)
4295 -1
4296 sage: K.recognize_in_subfield(m, [a^3 + a])
4297 (-1)
4298
4299 sage: m(a^2)
4300 Traceback (most recent call last):
4301 ...
4302 TypeError: a^2 must be coercible into Number
Field in b with defining polynomial x^2 + 100
4303
4304 sage: K.recognize_in_subfield(m, [a^2])
4305 Traceback (most recent call last):
4306 ...
4307 ValueError: Not all elements are in subfield
}}}
I would be happy to move lots of EXAMPLES:: to TESTS::. But this is a
tricky function -- even with me doctesting this in tons of situations, of
large degree, varying numbers of elements, etc, relative extensions --
even with all that, you claim to have found a bug. So removing doctests?
Each one of which I have written to test a different situation? That's
crazy.
Why don't we rename {{{recognize_in_subfield}}} to
{{{_recognize_many_in_subfield}}} and add a {{{recognize_in_subfield}}}
with a simpler docstring that does the list wrapping. But please, I am
the user who needs to recognize many elements in a subfield so I want that
functionality to be available.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/6079#comment:12>
Sage <http://sagemath.org/>
Sage - Open Source Mathematical Software: Building the Car Instead of
Reinventing the Wheel
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
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-trac?hl=en
-~----------~----~----~----~------~----~------~--~---
