#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 fwclarke):
Replying to [comment:12 ncalexan]:
> 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!
I don't know what you mean by "the functionality that you want to reduce
this function to" . I didn't really want to change the functionality
(apart from allowing single elements).
I had read your first doctest, but
1. I couldn't see why you should start with a non-standard, slightly
complicated instance of the function's use, followed by how to get the
same answer a different way using "exotic" means, i.e., `coerce_map_from`
and `section` (exotic anyway from the point of view of a number theorist
who knows little about how SAGE works).
2. This first test is specifically about the base field as subfield, in
some sense the only ''genuine'' subfield there is (along, I suppose, with
its base field, and so on). For SAGE's subfields, as given by the
`subfield` and `subfields` functions, are just a field with a embedding
(so also created by the `embeddings` function).
3. AHAH! I see now that there must be a typo. Where you wrote `m(a^3 +
a)` and `m(a^2)`, you surely meant `n(a^3 + a)` and `n(a^2)` (and for the
latter the error message is different).
4. This way of getting an element into the base_field (if it's possible)
is entirely unnecessary. In your example:
{{{
sage: K.<a, b> = NumberField([x^3 + x + 1, x^2 + 100])
sage: a^3 + a
-1
}}}
so
{{{
sage: a^3 + a in K.base_field()
True
}}}
while
{{{
sage: a^2 in K.base_field()
False
}}}
Certainly we have
{{{
sage: z = a^3 + a
sage: z.parent() == K
True
}}}
But if we want to think of `z` as an element of the base field, then we
can convert it:
{{{
sage: w = K.base_field()(z)
sage: w.parent()
Number Field in b with defining polynomial x^2 + 100
}}}
But coercion means that we shouldn't usually need to do this. For example
{{{
sage: K.base_field().gen() + z
b - 1
}}}
> 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.
I don't think that in essence it is so tricky. Once the problem is
converted to linear algebra, using the `absolute_vector_space` function
(which is hopefully sufficiently doctested), it's relatively
straightforward. Certainly the doctests need to contain a variety of
cases, but I don't see why in your second example you need to run through
''all'' the quadratic subfields of `L`. And what's the point of a random
test with such a long output?
> 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.
This seems sensible. But I don't actually see what's wrong with allowing
''either'' a single element ''or'' a list (as does `NumberField`). Just
have
{{{
if not isinstance(elements_of_self, (list, tuple)):
elements_of_self = [elements_of_self]
}}}
at the beginning of the code and then at the end something like
{{{
if len(answer) == 1:
answer = answer[0]
return answer
}}}
I'll try to look the rest of the patch tomorrow.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/6079#comment:13>
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
-~----------~----~----~----~------~----~------~--~---
