This one should be false as QQbar comes with an embedding into CC,
but F does not (in other words, there is no canonical embedding of F
into QQbar). The a^2 in QQbar is a bug though.
- Robert
>
> Dear Michael,
>
> On Nov 26, 11:34 am, mabshoff <Michael.Absh...@mathematik.uni-
> dortmund.de> wrote:
>> please open a ticket. I would guess as you did that those two
>> related.
>
> Done, it is # 4621.
>
> By the way, the above problem appears even more directly:
> sage: F.<a>= NumberField(x^2-2)
> sage: 2 in QQbar
> True
> sage: F(2) in QQbar
> False
>
> Although F has no canonical embedding into QQbar, my understanding is
> that there is a hopefully unique maximal subfield of F that does have
> a canonical embedding into QQbar.
Into the mathematical \bar{Q}, yet. Sage's QQbar is \bar{Q} with a
choice of embedding into \C, and as F does not have a (chosen)
embedding into \C it doesn't have a chosen embedding into QQbar.
> If this is correct, there could be a
> method F.max_subfield_coercing_into(QQbar), and since F(2) is in that
> subfield, one has a reason to expect `F(2) in QQbar` to be True.
One *does* expect F(2) to be in QQbar, the same that one expects the
rational number 4/2 to be in ZZ, so I agree that the above is a bug.
- Robert
Yep. Note that once that number field coercion code gets merged,
QuadraticField(2) will have a preferred embedding into CC, and hence
QQbar.
> Of course, the image of 2 will be the same with each:
>
> sage: twos = [f(2) for f in F.embeddings(QQbar)]
> sage: twos
> [2, 2]
> sage: twos[0] == twos[1]
> True
>
> But note that this crashes horribly:
> sage: twos[1] == 2
> True
> sage: twos[1] == F(2)
> ----------------------------------------------------------------------
> -----
> TypeError (etc)
Yep. One just needs to fix the __call__ method of QQbar.
- Robert