Re: [sage-nt] is_isomorphic for relative extensions

[John Cremona]

[Welcome to sage-nt, Rob!]

I cannot see a pari function which does this so it would implementing
directly, and I agree that this would be useful. That would not be
hard since you would have the polynomials in K[X] defining each
extension and would just need to see whether one had any roots in the
other field.

Feel free to open a trac ticket for this (after checking that there is
not one already).

John

On 5 April 2013 08:27, Rob Harron <robert...@gmail.com> wrote:
> Given two relative extensions L1 and L2 of some base number field K, I would
> expect L1.is_isomorphic(L2) to return true if L1 is isomorphic to L2 *over
> K*. Maybe we should, as with many other functions, have
> is_isomorphic_relative and is_isomorphic_absolute. Thoughts?
>
> Rob
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-nt" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-nt+u...@googlegroups.com.
> To post to this group, send an email to sag...@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-nt?hl=en-GB.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Nils Bruin]

On Apr 5, 12:27 am, Rob Harron <robert.har...@gmail.com> wrote:
> Given two relative extensions L1 and L2 of some base number field K, I
> would expect L1.is_isomorphic(L2) to return true if L1 is isomorphic to L2
> *over K*

On one hand I agree with you (it's definitely the easier thing to
decide):

sage: K.<i>=NumberField(x^2+1)
sage: P.<X>=K[]
sage: L.base_field()
Number Field in i with defining polynomial x^2 + 1

But sage's concept of the category in which the thing lies suggests a
laxer concept of isomorphism:

sage: L.category()
Category of number fields

> Maybe we should, as with many other functions, have
> is_isomorphic_relative and is_isomorphic_absolute. Thoughts?

That would disambiguate the issue for sure. However, from a
mathematical point of view it would be nice if we could solve
questions like this by placing the object under consideration in the
appropriate category.

[Rob Harron]

Yeah, I can see that. To me, this means we should redo categories for number fields. For instance:

sage: K = NumberField(x^2+1, 'i')

sage: L = K.extension(x^2-5, 'a')

sage: L.base_field()

Number Field in i with defining polynomial x^2 + 1

sage: L.base_ring()

Number Field in i with defining polynomial x^2 + 1

sage: L.base()

Rational Field

The fact that the last is different from the first two is kind of weird (or maybe it isn't, but there's no docstring for .base). Furthermore, the first two make me think that L is an object in a category "over K", though it's not. And certainly mathematically, relative number fields over K should be in some category over K (the category of finite etale K-algebras would be nice, but I digress). Should we make number fields a category_over_base_ring? (From looking at Category_singleton, it looks like maybe that would slow things down?)

Either way, one could implement .is_isomorphic_relative, so I'll go ahead to do that.

Rob

[Rob Harron]

Alright, I've made a patch to implement a relative version of is_isomorphic and it's ready for review at http://trac.sagemath.org/sage_trac/ticket/14424.

Rob

[Nils Bruin]

On Apr 5, 3:44 pm, Rob Harron <robert.har...@gmail.com> wrote:
> Yeah, I can see that. To me, this means we should redo categories for
> number fields. For instance:
>
> sage: K = NumberField(x^2+1, 'i')
> sage: L = K.extension(x^2-5, 'a')
> sage: L.base_field()
> Number Field in i with defining polynomial x^2 + 1
> sage: L.base_ring()
> Number Field in i with defining polynomial x^2 + 1
> sage: L.base()
> Rational Field

That does seem odd, but it's easily explained by looking at where the
routine comes from (never mind that base SHOULD have a docstring):

sage: [f for f in type(L).mro() if 'base_field' in f.__dict__]
[<class
'sage.rings.number_field.number_field_rel.NumberField_relative'>]
sage: [f for f in type(L).mro() if 'base' in f.__dict__]
[<type 'sage.structure.category_object.CategoryObject'>]
sage: [f for f in type(L).mro() if 'base_ring' in f.__dict__]
[<class
'sage.rings.number_field.number_field_rel.NumberField_relative'>,
<type 'sage.structure.category_object.CategoryObject'>]

so one routine comes from NumberFields itself, the other one from the
category framework. As you can see, `base_ring` is implemented at
both, so there we can really get contradictory answers. Of course, the
one on NumberField_relative shadows the more general one, so we get

sage: L.base_ring()
Number Field in i with defining polynomial x^2 + 1
sage:

sage.rings.number_field.number_field_rel.NumberField_relative.base_ring(L)

Number Field in i with defining polynomial x^2 + 1

but:

sage: sage.structure.category_object.CategoryObject.base_ring(L)
Rational Field

so the category framework at the moment is indeed not in agreement
with what the more specific class thinks about itself and since both
decide to implement base_ring, these two views could easily clash.

Incidentally, there IS a docstring that makes locating the source of
"base" a little easier:

sage: L.base.__doc__
'File: sage/structure/category_object.pyx (starting at line 564)'