Opened 5 years ago

Last modified 22 months ago

#18036 new defect

I should not be symbolic — at Version 6

Reported by: vdelecroix Owned by:
Priority: major Milestone: sage-6.6
Component: number fields Keywords:
Cc: wuthrich, jdemeyer, mmezzarobba, behackl, rws Merged in:
Authors: Reviewers:
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Description (last modified by kcrisman)

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.

Change History (6)

comment:1 follow-ups: Changed 5 years ago by 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.

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.

comment:2 in reply to: ↑ 1 ; follow-up: Changed 5 years ago by vdelecroix

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

comment:3 Changed 5 years ago by jdemeyer

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).

comment:4 in reply to: ↑ 1 Changed 5 years ago by jdemeyer

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.

comment:5 in reply to: ↑ 2 Changed 5 years ago by pbruin

Replying to vdelecroix:

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.)

comment:6 Changed 5 years ago by kcrisman

  • Description modified (diff)

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.

Note: See TracTickets for help on using tickets.