Infinite recursion when trying to construct a number field morphism

[Simon King]

Hi!

The following code results in an infinite recursion:
sage: L.<i> = NumberField(x^2 + 1)
sage: K = NumberField(L(i/2+3).minpoly(), names=('i0',), embedding=L(i/2+3))
sage: from sage.rings.number_field import number_field_morphisms
sage: number_field_morphisms.EmbeddedNumberFieldMorphism(K, L)

I suppose that we don't want this map to exist. But why?

Please suggest a quick check that can be done in
EmbeddedNumberFieldMorphism.__init__, so that we can raise a TypeError
or ValueError, rather than running into an infinite recursion.

This is important for trac ticket #15303, which is about making the
coercion system behave as it should.

Best regards,
Simon

[Simon King]

Am Donnerstag, 24. Oktober 2013 14:10:25 UTC+2 schrieb Simon King:

Hi!

The following code results in an infinite recursion:
  sage: L.<i> = NumberField(x^2 + 1)
  sage: K = NumberField(L(i/2+3).minpoly(), names=('i0',), embedding=L(i/2+3))
  sage: from sage.rings.number_field import number_field_morphisms
  sage: number_field_morphisms.EmbeddedNumberFieldMorphism(K, L)

I suppose that we don't want this map to exist. But why?

Since nobody answered, I am suggesting a reason:  K is an embedded number field (it is embedded in L), but L is not an embedded number field, as L.coerce_embedding() returns None. It seems odd to try and create an embedded number field morphism, if one of the number fields involved is not embedded.

Hence, I suggest that EmbeddedNumberFieldMorphism(K, L) should test whether both K and L have a registered coerce embedding. If they have, then the embedded number field morphism will assume that the ambient field is the pushout of the codomains of the two coerce embeddings. Otherwise, a TypeError is raised, because one of the two number fields is not embedded. And of course it will remain possible to provide an ambient field by an optional argument.

Does this make sense to the number theorists among you?

Best regards,
Simon

[David Roe]

The docstring of EmbeddedNumberFieldMorphism already says that it requires both K and L to be embedded in the ambient field, so I guess the issue is how to determine what the ambient field is when the user doesn't supply it?  Your solution sounds reasonable in this case.
David

--
You received this message because you are subscribed to the Google Groups "sage-algebra" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sage-algebra...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Nils Bruin]

On Friday, October 25, 2013 1:36:52 PM UTC-7, Simon King wrote:

Hence, I suggest that EmbeddedNumberFieldMorphism(K, L) should test whether both K and L have a registered coerce embedding. If they have, then the embedded number field morphism will assume that the ambient field is the pushout of the codomains of the two coerce embeddings.

Some experiments suggest to me that  sage.categories.pushout.pushout for number fields might be using EmbeddedNumberFieldMorphism itself, so doing a full pushout might be a bit much to ask (in case people embed number fields in other number fields or perhaps even into themselves, which they shouldn't do). Perhaps just insist that one of the codomains is coercible in the other?

[Nils Bruin]

On Saturday, October 26, 2013 6:03:49 AM UTC-7, Simon King wrote:

  sage: from sage.categories.pushout import pushout
  sage: pushout(Qp(7),RLF)
  Traceback (most recent call last):
  ...
  RuntimeError: maximum recursion depth exceeded while calling a Python object

What result would you expect as pushout? Should a CoercionException be
raised?

I guess it could push out to the adelic ring if we had it, but CoercionException should be quite acceptable