#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'm withdrawing the second patch for the time being (even though the
uniqueness problem was wrong -- it was unique, I was confused). All of
these comments seem to be about the second patch; if that's true, can we
just review the first patch? I've responded to your comments anyway.
Replying to [comment:7 fwclarke]:
> Replying to [comment:6 ncalexan]:
> > Please disregard the second patch for the time being. The result is
not unique, at least not in some cases I thought it would be, and I have
to deduce the correct conditions on the embeddings to make it unique.
>
> I would have thought that the simplest way to implement the function
would be by a recursive use of `relativize`.
So did I. After trying to do a recursive relativize, I came to this. (I
found this method to work a lot better, but that was before my patches
making relativize work quickly were in place.)
'''Except''' this function does not, in my opinion, work correctly with
relative extensions. If L/K is a relative extensions, and alpha is in L,
then `L.relativize(alpha, 'alpha') returns the relative extension
L/QQ(alpha). I think it would be much more useful if it returned
L/K(alpha). This should be easy to fix, and then `subfields_containing`
would follow, including the relative case.
Look, this is just not what relativize does:
{{{
Given an element in self or an embedding of a subfield into self,
return a relative number field $K$ isomorphic to self that is
relative
over the absolute field $\QQ(\alpha)$ or the domain of $alpha$,
along
with isomorphisms from $K$ to self and from self to K.
}}}
This behaviour was in place before I started improving it; I'm not averse
to changing it, but then we have to deprecate and add new names, etc.
That's what I'm doing -- adding new names for new functionality.
>
> Some other remarks :
>
> I take the point about the difference between `subfield` and
> `subfield_containing` (I didn't read carefully enough), but there needs
to be a reference to the latter in
> the documentation for the former.
Fine.
> However the function is implemented, `K.subfields_containing([a],
'b')[:2]` and
> `K.subfield(a, 'b')` should give the same answer.
They don't do the same thing. If you want to make them do the same thing,
that could be done. But nowhere do I claim that they do the same thing.
> It should be possible to leave the name out as in
Nope -- explicit is always the way in Sage.
> {{{
> sage: C.<z> = CyclotomicField(20)
> sage: C.subfield(z^4)
> (Number Field in z0 with defining polynomial x^4 + x^3 + x^2 + x + 1,
> Ring morphism:
> From: Number Field in z0 with defining polynomial x^4 + x^3 + x^2 + x
+ 1
> To: Cyclotomic Field of order 20 and degree 8
> Defn: z0 |--> z^4)
> }}}
>
> I suggest there's a doctest looking like
> {{{
> sage: D.<u>, phi, alphas = C.subfield_containing([z^4, z^6])
> sage: alphas
> (1/4*u2^2, 1/8*u2^3)
> sage: phi
> sage: map(phi, alphas)
> [z^4, z^6]
There are -- several.
> }}}
> But, at present,
> {{{
> sage: u
> u2
> }}}
> which can't be right.
Well, maybe. Look at subfields and several of the other functions which
take a name parameter -- it doesn't mean what you think it means. It's
annoying, and I'd like it to be fixed, but that's not the subject of this
patch.
> I note that the corresponding
> {{{
> sage: D.<w>, phi = C.subfield(z^4)
> }}}
> fails because the variable name in `subfield` is `name` rather than
`names`.
> I'll open a ticket for this.
Please do.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/6079#comment:8>
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
-~----------~----~----~----~------~----~------~--~---
