I.parent() should not be the symbolic ring

[videlec]

As suggested in #7545, this ticket defines the imaginary unit I directly as the generator of QuadraticField(-1) instead of wrapping it in a symbolic expression.

Why? To allow it to be used in combination with elements of QQbar, CC, etc., without coercion forcing the expression to SR. For example, 1.0 + I is now an element of CC instead of SR.

How? We set I in sage.all to the generator of ℚ[i], and deprecate importing it from sage.symbolic.I. The symbolic I remains available from sage.symbolic.constants for library code working with symbolic expressions, and as SR(I) or SR.I(). We create a dedicated subclass of quadratic number field elements to make it possible to support features similar to those of symbolic expressions of the form a + I*b that would not make sense for number field elements (or be too hard to implement, or pollute the namespace).

Why not ℤ[i]? Because the class hierarchy of number field and order elements makes it difficult to provide the compatibility features mentioned above for elements of both ℤ[i] and ℚ[i]. Having I be an element of ℚ[i] covers almost all use cases (all except working with algebraic integers?), and people who work with orders are sophisticated enough to explicitly ask for I ∈ ℤ[i] when they need that. (This is a debatable choice. We could probably do without the dedicated subclass for elements of ℚ[i], at the price of breaking backward compatibility a bit more.)

CC: @categorie @jdemeyer @mezzarobba @behackl @rwst @kliem @mwageringel

Component: number fields

Author: Marc Mezzarobba

Branch/Commit: 54a34a7

Reviewer: Vincent Delecroix

Issue created by migration from https://trac.sagemath.org/ticket/18036

[nbruin]

comment:1

I'm not so sure it should. Which quadratic field is the appropriate one? There are many, distinguishable by the name of their generator (that would be 'I') for this one, but also by their specified embeddings, and it's not clear which one to choose.

Is there an argument for doing this? Ticket #17860 referenced in the description makes no mention of it. I'd imagine there might be evaluation reasons that might make it attractive. Perhaps those also give an indication of which quadratic field would be the appropriate one.

[videlec]

comment:2

Replying to @nbruin:

I'm not so sure it should. Which quadratic field is the appropriate one? There are many, distinguishable by the name of their generator (that would be 'I') for this one, but also by their specified embeddings, and it's not clear which one to choose.

I also thought of this in the train... and I do not see much possible choices. I found two rather natural choices for the adoption of I:

• the ring of integers Z[sqrt(-1)] with its natural embedding in QQbar
• QQbar itself

Is there an argument for doing this? Ticket #17860 referenced in the description makes no mention of it. I'd imagine there might be evaluation reasons that might make it attractive. Perhaps those also give an indication of which quadratic field would be the appropriate one.

Some reasons (in favor of the first choice):

• I + 1.0 and 1.0 * I should be complex numbers
• factor((I+3)) should be the factorization over the Gaussian integers (i.e. (-I) * (I + 1) * (2*I + 1))
• abs(I) should be the integer 1

Vincent

[jdemeyer]

comment:3

I should be an element of QuadraticField(-1, 'I', embedding=CC.gen(), latex_name='i'), which is what it currently is (see src/sage/symbolic/pynac.pyx).

[jdemeyer]

comment:4

Replying to @nbruin:

Is there an argument for doing this?

In short: the same reason that 1 is not symbolic. When doing basic arithmetic with I, there is no need for a symbolic I. Whenever something symbolic is needed, coercion will make it symbolic.

[pjbruin]

comment:5

Replying to @videlec:

I found two rather natural choices for the adoption of I:

• the ring of integers Z[sqrt(-1)] with its natural embedding in QQbar

The ring ZZ[sqrt(-1)] definitely looks like the most natural choice to me, since admits a canonical homomorphism to any other ring with a distinguished square root of -1.

As for the distinguished embedding, is there a specific reason for choosing QQbar? A more minimal choice would be to fix an embedding into a UniversalCyclotomicField; then we would have coercion maps ZZ[I] -> UniversalCyclotomicField(zeta) -> QQbar -> CC. (Maybe this makes finding common parents slightly harder, though.)

[kcrisman]

Description changed:

--- 
+++ 
@@ -1,3 +1,3 @@
-As suggested in #17860, `I` (so that `I^2 = -1`) should be defined directly as the generator of `QuadraticField(-1)` and not wrapped into a symbolic expression.
+As suggested in #7545, `I` (so that `I^2 = -1`) should be defined directly as the generator of `QuadraticField(-1)` and not wrapped into a symbolic expression.
 
 Currently, `I` is defined in `sage/symbolic/pynac.pyx` within the function `init_pynac_I`.

[kcrisman]

comment:6

Thank you all for working on this - this kind of thing has been on the radar for years but after Burcin left day-to-day operations around here there hasn't been the combination of energy and know-how to do this "correctly", whatever that might mean. Just keep in mind it would be nice for I in SR to be true, though I'm sure it will be since 1 in SR already is True. I do like the idea of abs(I) being an Integer and not a symbolic expression.

[mezzarobba]

comment:8

Proof of concept to see what would break: u/mmezzarobba/18036-QQi (I'm using a number field element for now, not an order element, but switching shouldn't be hard). Still needs quite a bit of work, but all tests should pass (I didn't run them all with the last version of the code). Any comment or improvement welcome!

In particular:

• Are there behavior changes that you think are not acceptable, or not acceptable without a deprecation?
• I'm not happy with the changes to sage.geometry.hyperbolic_space (which apparently relied on operations involving I triggering coercions to SR), but I don't understand the code well enough to do better.

Tangentially related: now may be a good time to deprecate (or remove directly?) the bogus coercion from SR to QQbar.

[mezzarobba]

comment:9

As it turns out, there are a few failures in complex_mpc.pyx. But unless I'm mistaken these failures are solved by #14982. And conversely, the present ticket provides a real fix for a problem I only worked around in #14982.

[videlec]

comment:10

Very nice that it worked!

I do not quite understand why you need the creation of a new class of NumberFieldQQi... is that only for the special method you need in the element class?

For embedding in QQbar I guess that what should be fixed is embedding of number fields. In the ideal world, you would declare:

QQi = NumberField(x**2 + 1, 'I', embedding=QQbar.gen())

But then, there might be an infinite loop with the definition of I in QQbar. I had the same sort of troubles when refining default embedding from lazy field to AA/QQbar.

Vincent

[mezzarobba]

comment:11

Replying to @videlec:

I do not quite understand why you need the creation of a new class of NumberFieldQQi... is that only for the special method you need in the element class?

I don't remember, it could be that the reason no longer exists due to later changes.

For embedding in QQbar I guess that what should be fixed is embedding of number fields. In the ideal world, you would declare:

QQi = NumberField(x**2 + 1, 'I', embedding=QQbar.gen())

Yes, the idea is to switch to an embedding into QQbar when other number fields do.