Sage: Ticket #18036: I.parent() should not be the symbolic ring
https://trac.sagemath.org/ticket/18036
<p>
As suggested in <a class="closed ticket" href="https://trac.sagemath.org/ticket/7545" title="enhancement: Gaussian and Eisenstein integers (closed: fixed)">#7545</a>, <code>I</code> (so that <code>I^2 = -1</code>) should be defined directly as the generator of <code>QuadraticField(-1)</code> and not wrapped into a symbolic expression.
</p>
<p>
Currently, <code>I</code> is defined in <code>sage/symbolic/pynac.pyx</code> within the function <code>init_pynac_I</code>.
</p>
en-usSagehttps://trac.sagemath.org/chrome/site/logo_sagemath_trac.png
https://trac.sagemath.org/ticket/18036
Trac 1.1.6nbruinSun, 22 Mar 2015 18:16:04 GMT
https://trac.sagemath.org/ticket/18036#comment:1
https://trac.sagemath.org/ticket/18036#comment:1
<p>
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.
</p>
<p>
Is there an argument for doing this? Ticket <a class="closed ticket" href="https://trac.sagemath.org/ticket/17860" title="enhancement: Auto-generate gen.pyx -- part 2 (closed: fixed)">#17860</a> 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.
</p>
TicketvdelecroixSun, 22 Mar 2015 21:07:22 GMT
https://trac.sagemath.org/ticket/18036#comment:2
https://trac.sagemath.org/ticket/18036#comment:2
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/18036#comment:1" title="Comment 1">nbruin</a>:
</p>
<blockquote class="citation">
<p>
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.
</p>
</blockquote>
<p>
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 <code>I</code>:
</p>
<ul><li>the ring of integers <code>Z[sqrt(-1)]</code> with its natural embedding in <code>QQbar</code>
</li><li><code>QQbar</code> itself
</li></ul><blockquote class="citation">
<p>
Is there an argument for doing this? Ticket <a class="closed ticket" href="https://trac.sagemath.org/ticket/17860" title="enhancement: Auto-generate gen.pyx -- part 2 (closed: fixed)">#17860</a> 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.
</p>
</blockquote>
<p>
Some reasons (in favor of the first choice):
</p>
<ul><li><code>I + 1.0</code> and <code>1.0 * I</code> should be complex numbers
</li><li><code>factor((I+3))</code> should be the factorization over the Gaussian integers (i.e. <code>(-I) * (I + 1) * (2*I + 1)</code>)
</li><li><code>abs(I)</code> should be the integer <code>1</code>
</li></ul><p>
Vincent
</p>
TicketjdemeyerSun, 22 Mar 2015 22:17:35 GMT
https://trac.sagemath.org/ticket/18036#comment:3
https://trac.sagemath.org/ticket/18036#comment:3
<p>
<code>I</code> should be an element of <code>QuadraticField(-1, 'I', embedding=CC.gen(), latex_name='i')</code>, which is what it currently is (see <code>src/sage/symbolic/pynac.pyx</code>).
</p>
TicketjdemeyerSun, 22 Mar 2015 22:27:00 GMT
https://trac.sagemath.org/ticket/18036#comment:4
https://trac.sagemath.org/ticket/18036#comment:4
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/18036#comment:1" title="Comment 1">nbruin</a>:
</p>
<blockquote class="citation">
<p>
Is there an argument for doing this?
</p>
</blockquote>
<p>
In short: the same reason that <code>1</code> is not symbolic. When doing basic arithmetic with <code>I</code>, there is no need for a symbolic <code>I</code>. Whenever something symbolic is needed, coercion will make it symbolic.
</p>
TicketpbruinTue, 24 Mar 2015 17:08:05 GMT
https://trac.sagemath.org/ticket/18036#comment:5
https://trac.sagemath.org/ticket/18036#comment:5
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/18036#comment:2" title="Comment 2">vdelecroix</a>:
</p>
<blockquote class="citation">
<p>
I found two rather natural choices for the adoption of <code>I</code>:
</p>
<ul><li>the ring of integers <code>Z[sqrt(-1)]</code> with its natural embedding in <code>QQbar</code>
</li></ul></blockquote>
<p>
The ring <code>ZZ[sqrt(-1)]</code> 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.
</p>
<p>
As for the distinguished embedding, is there a specific reason for choosing <code>QQbar</code>? A more minimal choice would be to fix an embedding into a <code>UniversalCyclotomicField</code>; then we would have coercion maps <code>ZZ[I]</code> -> <code>UniversalCyclotomicField(zeta)</code> -> <code>QQbar</code> -> <code>CC</code>. (Maybe this makes finding common parents slightly harder, though.)
</p>
TicketkcrismanTue, 24 Mar 2015 18:08:10 GMTdescription changed
https://trac.sagemath.org/ticket/18036#comment:6
https://trac.sagemath.org/ticket/18036#comment:6
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/18036?action=diff&version=6">diff</a>)
</li>
</ul>
<p>
Thank you all for working on this - this kind of thing has been on the radar for <a class="closed ticket" href="https://trac.sagemath.org/ticket/7545#comment:5" title="Comment 5 for Ticket #7545">years</a> 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 <code>I in SR</code> to be true, though I'm sure it will be since <code>1 in SR</code> already is <code>True</code>. I do like the idea of <code>abs(I)</code> being an <code>Integer</code> and not a symbolic expression.
</p>
TicketmmezzarobbaWed, 15 Apr 2015 05:45:47 GMTcc changed
https://trac.sagemath.org/ticket/18036#comment:7
https://trac.sagemath.org/ticket/18036#comment:7
<ul>
<li><strong>cc</strong>
<em>mmezzarobba</em> added
</li>
</ul>
TicketmmezzarobbaWed, 15 Apr 2015 14:18:18 GMT
https://trac.sagemath.org/ticket/18036#comment:8
https://trac.sagemath.org/ticket/18036#comment:8
<p>
Proof of concept to see what would break: <code>u/mmezzarobba/18036-QQi</code> (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!
</p>
<p>
In particular:
</p>
<ul><li>Are there behavior changes that you think are not acceptable, or not acceptable without a deprecation?
</li><li>I'm not happy with the changes to <code>sage.geometry.hyperbolic_space</code> (which apparently relied on operations involving <code>I</code> triggering coercions to <code>SR</code>), but I don't understand the code well enough to do better.
</li></ul><p>
Tangentially related: now may be a good time to deprecate (or remove directly?) the bogus coercion from <code>SR</code> to <code>QQbar</code>.
</p>
TicketmmezzarobbaWed, 15 Apr 2015 15:27:47 GMT
https://trac.sagemath.org/ticket/18036#comment:9
https://trac.sagemath.org/ticket/18036#comment:9
<p>
As it turns out, there are a few failures in <code>complex_mpc.pyx</code>. But unless I'm mistaken these failures are solved by <a class="closed ticket" href="https://trac.sagemath.org/ticket/14982" title="defect: When a parent is equipped with an embedding, consider coercions that ... (closed: fixed)">#14982</a>. And conversely, the present ticket provides a real fix for a problem I only worked around in <a class="closed ticket" href="https://trac.sagemath.org/ticket/14982" title="defect: When a parent is equipped with an embedding, consider coercions that ... (closed: fixed)">#14982</a>.
</p>
TicketvdelecroixWed, 15 Apr 2015 16:54:56 GMT
https://trac.sagemath.org/ticket/18036#comment:10
https://trac.sagemath.org/ticket/18036#comment:10
<p>
Very nice that it worked!
</p>
<p>
I do not quite understand why you need the creation of a new class of <code>NumberFieldQQi</code>... is that only for the special method you need in the element class?
</p>
<p>
For embedding in QQbar I guess that what should be fixed is embedding of number fields. In the ideal world, you would declare:
</p>
<pre class="wiki">QQi = NumberField(x**2 + 1, 'I', embedding=QQbar.gen())
</pre><p>
But then, there might be an infinite loop with the definition of <code>I</code> in <code>QQbar</code>. I had the same sort of troubles when refining default embedding from lazy field to <code>AA/QQbar</code>.
</p>
<p>
Vincent
</p>
TicketmmezzarobbaWed, 15 Apr 2015 17:13:37 GMT
https://trac.sagemath.org/ticket/18036#comment:11
https://trac.sagemath.org/ticket/18036#comment:11
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/18036#comment:10" title="Comment 10">vdelecroix</a>:
</p>
<blockquote class="citation">
<p>
I do not quite understand why you need the creation of a new class of <code>NumberFieldQQi</code>... is that only for the special method you need in the element class?
</p>
</blockquote>
<p>
I don't remember, it could be that the reason no longer exists due to later changes.
</p>
<blockquote class="citation">
<p>
For embedding in QQbar I guess that what should be fixed is embedding of number fields. In the ideal world, you would declare:
</p>
<pre class="wiki">QQi = NumberField(x**2 + 1, 'I', embedding=QQbar.gen())
</pre></blockquote>
<p>
Yes, the idea is to switch to an embedding into QQbar when other number fields do.
</p>
TicketmmezzarobbaSat, 18 Apr 2015 11:13:05 GMT
https://trac.sagemath.org/ticket/18036#comment:12
https://trac.sagemath.org/ticket/18036#comment:12
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/18036#comment:11" title="Comment 11">mmezzarobba</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/18036#comment:10" title="Comment 10">vdelecroix</a>:
</p>
<blockquote class="citation">
<p>
I do not quite understand why you need the creation of a new class of <code>NumberFieldQQi</code>... is that only for the special method you need in the element class?
</p>
</blockquote>
<p>
I don't remember, it could be that the reason no longer exists due to later changes.
</p>
</blockquote>
<p>
One reason was that having separate classes makes it easy to test if we are in the special case of QQ[i] using <code>isinstance</code>. In the case of the parent class, this is convenient when specifying coercions, for instance.
</p>
TicketvdelecroixSat, 18 Apr 2015 11:27:45 GMT
https://trac.sagemath.org/ticket/18036#comment:13
https://trac.sagemath.org/ticket/18036#comment:13
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/18036#comment:12" title="Comment 12">mmezzarobba</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/18036#comment:11" title="Comment 11">mmezzarobba</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/18036#comment:10" title="Comment 10">vdelecroix</a>:
</p>
<blockquote class="citation">
<p>
I do not quite understand why you need the creation of a new class of <code>NumberFieldQQi</code>... is that only for the special method you need in the element class?
</p>
</blockquote>
<p>
I don't remember, it could be that the reason no longer exists due to later changes.
</p>
</blockquote>
<p>
One reason was that having separate classes makes it easy to test if we are in the special case of QQ[i] using <code>isinstance</code>. In the case of the parent class, this is convenient when specifying coercions, for instance.
</p>
</blockquote>
<p>
Anyway this will be instantiated at startup so why not keeping one instance <code>QQi</code> in <code>sage.rings.number_field.number_field</code>? (like we have for <code>ZZ</code>, <code>QQ</code>, etc). Then you can test identity when testing coercions.
</p>
TicketmmezzarobbaSat, 18 Apr 2015 16:56:16 GMT
https://trac.sagemath.org/ticket/18036#comment:14
https://trac.sagemath.org/ticket/18036#comment:14
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/18036#comment:13" title="Comment 13">vdelecroix</a>:
</p>
<blockquote class="citation">
<p>
Anyway this will be instantiated at startup so why not keeping one instance <code>QQi</code> in <code>sage.rings.number_field.number_field</code>? (like we have for <code>ZZ</code>, <code>QQ</code>, etc).
</p>
</blockquote>
<p>
If I remember right, currently, just adding <code>QQi = ...()</code> in the module currently doesn't work due to import order constraints. For now I just kept the creation of QQ[i] happening at the same time as it used to. But that's certainly something we should try to improve after this first draft.
</p>
<blockquote class="citation">
<p>
Then you can test identity when testing coercions.
</p>
</blockquote>
<p>
Yes. Having a separate class would also be natural if we want <code>I.parent()</code> to display something less frightening than “Number Field in <code>I</code> with defining polynomial <code>x^2 + 1</code>”, and more generally to implement features specific to QQ[i]. But I can't really think of anything that makes sense for this field and not for embedded quadratic number fields in general, so perhaps it is better to encourage people to always implement a more general version?
</p>
<p>
A related question is whether <code>QQi is NumberField(x^2+1, 'I', embedding=CC.0)</code> should be true, or if there should be two separate parents.
</p>
<p>
What do you think?
</p>
TicketmmezzarobbaSun, 19 Apr 2015 05:57:31 GMTsummary changed
https://trac.sagemath.org/ticket/18036#comment:15
https://trac.sagemath.org/ticket/18036#comment:15
<ul>
<li><strong>summary</strong>
changed from <em>I should not be symbolic</em> to <em>I.parent() should not be the symbolic ring</em>
</li>
</ul>
TicketvdelecroixSun, 19 Apr 2015 11:17:07 GMT
https://trac.sagemath.org/ticket/18036#comment:16
https://trac.sagemath.org/ticket/18036#comment:16
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/18036#comment:14" title="Comment 14">mmezzarobba</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/18036#comment:13" title="Comment 13">vdelecroix</a>:
</p>
<blockquote class="citation">
<p>
Anyway this will be instantiated at startup so why not keeping one instance <code>QQi</code> in <code>sage.rings.number_field.number_field</code>? (like we have for <code>ZZ</code>, <code>QQ</code>, etc).
</p>
</blockquote>
<p>
If I remember right, currently, just adding <code>QQi = ...()</code> in the module currently doesn't work due to import order constraints. For now I just kept the creation of QQ[i] happening at the same time as it used to. But that's certainly something we should try to improve after this first draft.
</p>
</blockquote>
<p>
Here we can probably cheat with
</p>
<pre class="wiki">_QQi = None
def NumberFieldQQi():
if _QQi is None:
# build it once for all
...
return _QQi
</pre><blockquote class="citation">
<blockquote class="citation">
<p>
Then you can test identity when testing coercions.
</p>
</blockquote>
<p>
Yes. Having a separate class would also be natural if we want <code>I.parent()</code> to display something less frightening than “Number Field in <code>I</code> with defining polynomial <code>x^2 + 1</code>”, and more generally to implement features specific to QQ[i]. But I can't really think of anything that makes sense for this field and not for embedded quadratic number fields in general, so perhaps it is better to encourage people to always implement a more general version?
</p>
</blockquote>
<p>
Yes! Having a custom representation should be done in the main class. It is already possible:
</p>
<pre class="wiki">sage: K = QuadraticField(2)
sage: K.rename('It's me')
sage: K
It's me
sage: K.rename(None)
sage: K
Number Field in a with defining polynomial x^2 - 2
</pre><blockquote class="citation">
<p>
A related question is whether <code>QQi is NumberField(x^2+1, 'I', embedding=CC.0)</code> should be true, or if there should be two separate parents.
</p>
<p>
What do you think?
</p>
</blockquote>
<p>
More generally, do we want unique representation for (absolute) number fields? I would tend to say yes. And the natural keys would be:
</p>
<ul><li>the polynomial
</li><li>the variable name (not of the polynomial!)
</li><li>the embedding
</li></ul><p>
Vincent
</p>
TicketmmezzarobbaSun, 19 Apr 2015 12:56:43 GMT
https://trac.sagemath.org/ticket/18036#comment:17
https://trac.sagemath.org/ticket/18036#comment:17
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/18036#comment:16" title="Comment 16">vdelecroix</a>:
</p>
<blockquote class="citation">
<p>
Yes! Having a custom representation should be done in the main class. It is already possible:
</p>
</blockquote>
<p>
If all we want is a different string representation, yes, perhaps it makes sense to use <code>rename()</code>...
</p>
<blockquote class="citation">
<blockquote class="citation">
<p>
A related question is whether <code>QQi is NumberField(x^2+1, 'I', embedding=CC.0)</code> should be true, or if there should be two separate parents.
</p>
<p>
What do you think?
</p>
</blockquote>
<p>
More generally, do we want unique representation for (absolute) number fields?
</p>
</blockquote>
<p>
I think everyone agrees that absolute number fields should have unique representation. My question was whether Q[i] should <em>be</em> an absolute number field in this sense, or if it should be a “special” object such that people could work with both Q[i]-as-a-subset-of-complex-numbers and Q[i]-as-a-number field, possibly at the same time. I'd prefer a single object as well, but I am sure I have missed some of the implications, so if anyone has arguments in favor of the other option, I would be interested in hearing them.
</p>
TicketvdelecroixSun, 19 Apr 2015 13:14:50 GMT
https://trac.sagemath.org/ticket/18036#comment:18
https://trac.sagemath.org/ticket/18036#comment:18
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/18036#comment:17" title="Comment 17">mmezzarobba</a>:
</p>
<blockquote class="citation">
<blockquote class="citation">
<blockquote class="citation">
<p>
A related question is whether <code>QQi is NumberField(x^2+1, 'I', embedding=CC.0)</code> should be true, or if there should be two separate parents.
</p>
<p>
What do you think?
</p>
</blockquote>
<p>
More generally, do we want unique representation for (absolute) number fields?
</p>
</blockquote>
<p>
I think everyone agrees that absolute number fields should have unique representation. My question was whether Q[i] should <em>be</em> an absolute number field in this sense, or if it should be a “special” object such that people could work with both Q[i]-as-a-subset-of-complex-numbers and Q[i]-as-a-number field, possibly at the same time. I'd prefer a single object as well, but I am sure I have missed some of the implications, so if anyone has arguments in favor of the other option, I would be interested in hearing them.
</p>
</blockquote>
<p>
I would be interested in working with <strong>any</strong> number field seeing them as a subfield of the real or complex numbers! Not only <code>QQi</code> and it makes sense to ask whether we need a dedicated class for that. For both parent and elements.
</p>
<p>
Note that it is already partly possible to play with element of number fields as real numbers (especially with quadratic fields)
</p>
<pre class="wiki">sage: K.<sqrt2> = QuadraticField(2)
sage: 1 < sqrt2 < 3/2
True
sage: sqrt2.n()
1.41421356237310
sage: sqrt2 + CC(0,1)
1.41421356237310 + 1.00000000000000*I
sage: sage: cos(sqrt2)
cos(sqrt(2))
sage: sqrt2.continued_fraction()
[1; (2)*]
</pre><p>
About having methods <code>.cos()</code>, <code>.sin()</code>, <code>.exp()</code>, it is already something which I found dangerous with integers for which the method <code>.sqrt()</code> might return an answer with a different parent
</p>
<pre class="wiki">sage: 4.sqrt() # answer is a Sage integer
2
sage: 2.sqrt() # answer is symbolic
sqrt(2)
</pre><p>
Which is very different from
</p>
<pre class="wiki">sage: R.<x> = ZZ[]
sage: ((x+1)**2 * (x-2)**4).sqrt()
x^3 - 3*x^2 + 4
sage: R(2).sqrt()
Traceback (most recent call last):
...
TypeError: Polynomial is not a square. You must specify
the name of the square root when using the default extend = True
</pre><p>
At the time Sage would support embedding of number fields into p-adic fields, I think it might be worse to have that dedicated class! But in the meantime, I have no strong opinion.
</p>
<p>
Vincent
</p>
TicketrwsSat, 17 Oct 2015 13:47:50 GMT
https://trac.sagemath.org/ticket/18036#comment:19
https://trac.sagemath.org/ticket/18036#comment:19
<p>
See also <a class="ext-link" href="https://groups.google.com/forum/?hl=en#!topic/sage-devel/Oa0kOC-VGds"><span class="icon"></span>https://groups.google.com/forum/?hl=en#!topic/sage-devel/Oa0kOC-VGds</a>
</p>
TicketjdemeyerTue, 05 Jan 2016 12:46:13 GMT
https://trac.sagemath.org/ticket/18036#comment:20
https://trac.sagemath.org/ticket/18036#comment:20
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/18036#comment:18" title="Comment 18">vdelecroix</a>:
</p>
<blockquote class="citation">
<p>
About having methods <code>.cos()</code>, <code>.sin()</code>, <code>.exp()</code>, it is already something which I found dangerous with integers
</p>
</blockquote>
<p>
Still, if we ever want this new non-symbolic <code>I</code> to behave like to old symbolic <code>I</code>, we would need to support things like that:
</p>
<pre class="wiki">**********************************************************************
File "src/sage/symbolic/expression.pyx", line 7901, in sage.symbolic.expression.Expression.log
Failed example:
I.log()
Exception raised:
Traceback (most recent call last):
File "/usr/local/src/sage-git/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 496, in _run
self.compile_and_execute(example, compiler, test.globs)
File "/usr/local/src/sage-git/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 858, in compile_and_execute
exec(compiled, globs)
File "<doctest sage.symbolic.expression.Expression.log[11]>", line 1, in <module>
I.log()
File "sage/structure/element.pyx", line 420, in sage.structure.element.Element.__getattr__ (build/cythonized/sage/structure/element.c:4676)
return getattr_from_other_class(self, P._abstract_element_class, name)
File "sage/structure/misc.pyx", line 259, in sage.structure.misc.getattr_from_other_class (build/cythonized/sage/structure/misc.c:1772)
raise dummy_attribute_error
AttributeError: 'sage.rings.number_field.number_field_element_quadratic.NumberFieldElement_quadratic' object has no attribute 'log'
**********************************************************************
</pre>
TicketjdemeyerTue, 05 Jan 2016 12:56:10 GMTbranch set
https://trac.sagemath.org/ticket/18036#comment:21
https://trac.sagemath.org/ticket/18036#comment:21
<ul>
<li><strong>branch</strong>
set to <em>u/jdemeyer/i_parent___should_not_be_the_symbolic_ring</em>
</li>
</ul>
TicketbehacklMon, 07 Mar 2016 09:57:49 GMTcc changed; commit set
https://trac.sagemath.org/ticket/18036#comment:22
https://trac.sagemath.org/ticket/18036#comment:22
<ul>
<li><strong>cc</strong>
<em>behackl</em> added
</li>
<li><strong>commit</strong>
set to <em>2f5a5198849c5b96bc2733e1e5853dc1b23f1cf9</em>
</li>
</ul>
<p>
New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=2f5a5198849c5b96bc2733e1e5853dc1b23f1cf9"><span class="icon"></span>2f5a519</a></td><td><code>parent(I) should be a number field</code>
</td></tr></table>
TicketrwsMon, 07 Mar 2016 09:58:24 GMTcc changed
https://trac.sagemath.org/ticket/18036#comment:23
https://trac.sagemath.org/ticket/18036#comment:23
<ul>
<li><strong>cc</strong>
<em>rws</em> added
</li>
</ul>
TicketbehacklMon, 07 Mar 2016 12:54:48 GMT
https://trac.sagemath.org/ticket/18036#comment:24
https://trac.sagemath.org/ticket/18036#comment:24
<p>
Hi! I'd like to revive this discussion a bit because we're getting a doctest failure at <a class="ext-link" href="https://github.com/pynac/pynac/pull/162"><span class="icon"></span>https://github.com/pynac/pynac/pull/162</a> which would probably be fixed along the lines of this ticket.
</p>
<p>
For starters, I had a look at the current branch and some of the resulting doctest failures; this should roughly resemble the tasks that are still to be done:
</p>
<ul><li><code>sage -t --warn-long 54.2 src/sage/symbolic/constants.py # 3 doctests failed</code>;
</li></ul><p>
<code>sage -t --warn-long 54.2 src/sage/symbolic/pynac.pyx # 3 doctests failed</code>:
</p>
<blockquote>
<p>
duplicate doctests. not sure how to fix (maybe switch to I_symbolic?). and which to remove.
</p>
</blockquote>
<ul><li><code>sage -t --warn-long 54.2 src/sage/symbolic/relation.py # 3 doctests failed</code>:
</li></ul><blockquote>
<p>
Doctests can be fixed directly.
</p>
</blockquote>
<ul><li><code>sage -t --warn-long 54.2 src/sage/symbolic/expression_conversions.py # 2 doctests failed</code>
</li></ul><blockquote>
<p>
probably I_symbolic is needed?
</p>
</blockquote>
<ul><li><code>sage -t --warn-long 54.2 src/sage/symbolic/expression.pyx # 14 doctests failed</code>
<ul><li> arithmetic with <code>oo</code> is broken (4 doctests)
</li><li> <code>_is_registered_constant_</code> --> remove doctest? I_symbolic?
</li><li> <code>is_numeric</code>/<code>is_constant</code> missing (I_symbolic?)
</li><li> <code>imag_part</code>/<code>real_part</code> should be an alias of <code>imag</code>/<code>real</code> (3 doctests)
</li><li> <code>I.log</code> not implemented (3 doctests)
</li><li><code>rectform</code>: either converse to SR or multiply with I_symbolic.
</li></ul></li></ul><ul><li><code>sage -t --warn-long 54.2 src/sage/rings/infinity.py # 2 doctests failed</code>
</li></ul><blockquote>
<p>
arithmetic with <code>oo</code> is broken.
</p>
</blockquote>
<ul><li><code>sage -t --warn-long 54.2 src/sage/rings/complex_mpc.pyx # 8 doctests failed</code> and <code>sage -t --warn-long 54.2 src/sage/rings/complex_arb.pyx # 7 doctests failed</code>
<ul><li>coercion errors: <code>ValueError: Cannot coerce algebraic number with non-zero imaginary part to algebraic real</code>
</li><li>precision regressions.
</li></ul></li></ul><ul><li><code>sage -t --warn-long 54.2 src/sage/rings/qqbar.py # 6 doctests failed</code>
</li></ul><p>
</p>
<blockquote>
<p>
common parent issue: <code>TypeError: unsupported operand parent(s) for '+': 'Algebraic Field' and 'Number Field in I with defining polynomial x^2 + 1'</code>
</p>
</blockquote>
<ul><li><code>sage -t --warn-long 54.2 src/sage/rings/number_field/number_field_element_quadratic.pyx # 1 doctest failed</code>
</li></ul><blockquote>
<p>
common parent issue: <code>TypeError: unsupported operand parent(s) for '*': 'Number Field in I with defining polynomial x^2 + 1' and 'Number Field in sqrt3 with defining polynomial x^2 - 3'</code>
</p>
</blockquote>
<ul><li><code>sage -t --warn-long 54.2 src/sage/rings/polynomial/polynomial_rational_flint.pyx # 1 doctest failed</code>
</li></ul><blockquote>
<p>
false error is raised
</p>
</blockquote>
<ul><li><code>sage -t --warn-long 54.2 src/sage/rings/polynomial/cyclotomic.pyx # 2 doctests failed</code>
</li></ul><blockquote>
<p>
both can be fixed directly.
</p>
</blockquote>
<ul><li>Stuff in <code>sage/geometry/hyperbolic_space/hyperbolic_*.py</code> breaks down:
<ul><li><code>sage -t --warn-long 51.1 src/sage/geometry/hyperbolic_space/hyperbolic_point.py # 1 doctest failed</code>
</li><li><code>sage -t --warn-long 51.1 src/sage/geometry/hyperbolic_space/hyperbolic_geodesic.py # 4 doctests failed</code>
</li><li><code>sage -t --warn-long 51.1 src/sage/geometry/hyperbolic_space/hyperbolic_isometry.py # 1 doctest failed</code>
</li><li><code>sage -t --warn-long 51.1 src/sage/geometry/hyperbolic_space/hyperbolic_model.py # 2 doctests failed</code>
</li></ul></li></ul><blockquote>
<p>
Not sure about these errors, some seem to be coercion related, others are just <code>TypeError: 'sage.rings.complex_number.ComplexNumber' object is not callable</code>---maybe that goes away along the way.
</p>
</blockquote>
<p>
These are certainly not all failures, but they should give an idea of what breaks down. The biggest issue seems to be coercion...
</p>
TicketjdemeyerMon, 07 Mar 2016 13:00:25 GMT
https://trac.sagemath.org/ticket/18036#comment:25
https://trac.sagemath.org/ticket/18036#comment:25
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/18036#comment:24" title="Comment 24">behackl</a>:
</p>
<blockquote class="citation">
<p>
The biggest issue seems to be coercion...
</p>
</blockquote>
<p>
And stuff like <code>I.log()</code>.
</p>
TicketrwsMon, 07 Mar 2016 14:46:26 GMT
https://trac.sagemath.org/ticket/18036#comment:26
https://trac.sagemath.org/ticket/18036#comment:26
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/18036#comment:24" title="Comment 24">behackl</a>:
</p>
<blockquote class="citation">
<ul><li><code>sage -t --warn-long 54.2 src/sage/rings/infinity.py # 2 doctests failed</code>
</li></ul><blockquote>
<p>
arithmetic with <code>oo</code> is broken.
</p>
</blockquote>
</blockquote>
<p>
It's just missing coercion of number field elements into the infinity ring. It would give a <code>SignError</code> anyway.
</p>
TicketkcrismanWed, 22 Jun 2016 20:09:12 GMT
https://trac.sagemath.org/ticket/18036#comment:27
https://trac.sagemath.org/ticket/18036#comment:27
<p>
Would
</p>
<pre class="wiki">A = GaussianIntegers()
A(1+I)
</pre><p>
work with this branch?
</p>
TicketrwsSat, 25 Jun 2016 06:32:47 GMT
https://trac.sagemath.org/ticket/18036#comment:28
https://trac.sagemath.org/ticket/18036#comment:28
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/18036#comment:27" title="Comment 27">kcrisman</a>:
</p>
<pre class="wiki">sage: A = GaussianIntegers()
sage: A(1+I)
I + 1
sage: type(_)
<type 'sage.rings.number_field.number_field_element_quadratic.OrderElement_quadratic'>
</pre>
TicketkcrismanSat, 25 Jun 2016 11:50:43 GMT
https://trac.sagemath.org/ticket/18036#comment:29
https://trac.sagemath.org/ticket/18036#comment:29
<p>
Thanks! That is definitely a motivation for me to review this next week ... any sense on whether the various doctest failures are "real", as opposed to just fixes like <a class="ticket" href="https://trac.sagemath.org/ticket/18036#comment:26" title="Comment 26">comment:26</a>?
</p>
TicketjdemeyerSat, 25 Jun 2016 16:29:37 GMT
https://trac.sagemath.org/ticket/18036#comment:30
https://trac.sagemath.org/ticket/18036#comment:30
<p>
What's a "real" doctest failure? Some features of <code>SR</code> simply are not supported for number field elements.
</p>
TicketrwsSun, 26 Jun 2016 13:02:25 GMT
https://trac.sagemath.org/ticket/18036#comment:31
https://trac.sagemath.org/ticket/18036#comment:31
<p>
So, we must have two different <code>I</code>s.
</p>
<p>
This interface duplication creates a similar problems to the one with pos.char. elements (either ring elements or symbolic <code>Mod</code>). I think what's most understandable to the user would be a switch that prevents mixing and whose value is clearly visible on startup like <code>symbolic I mode is ON</code>. I know this goes against the no globals rules but I predict no one will accept having to input <code>symbolic_I</code>, and we will get hell for that.
</p>
TicketnbruinSun, 26 Jun 2016 14:23:29 GMT
https://trac.sagemath.org/ticket/18036#comment:32
https://trac.sagemath.org/ticket/18036#comment:32
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/18036#comment:31" title="Comment 31">rws</a>:
</p>
<blockquote class="citation">
<p>
So, we must have two different <code>I</code>s.
</p>
</blockquote>
<p>
I've lost track what the exact issues are that lead to that conclusion, but I would definitely prefer if we don't do that. I think we can avoid it for the following reason:
</p>
<p>
Sage itself needs *many* different I's. For one thing, every <code>ComplexField(b)</code> needs its own. We'd like coercion to take care of creating the many different I's. I guess we're now finding it's difficult to find a parent that coerces into sufficiently many complex parents.
</p>
<p>
If that is the case, perhaps we should solve the problem by just having a <code>LiteralI</code>, just as we have <code>RealLiteral</code> to avoid the precision coercion problems that arise with floats. The advantage is that its coercion properties can be tailored exactly to what we need (within the bounds of what coercion can handle in the first place)
</p>
<p>
It doesn't surprise me that I is problematic that way. It is, after all, an object that represents multiple values.
</p>
TicketjdemeyerSun, 26 Jun 2016 15:19:36 GMT
https://trac.sagemath.org/ticket/18036#comment:33
https://trac.sagemath.org/ticket/18036#comment:33
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/18036#comment:31" title="Comment 31">rws</a>:
</p>
<blockquote class="citation">
<p>
So, we must have two different <code>I</code>s.
</p>
</blockquote>
<p>
We really should not do that. Ideally, <code>I</code> should be some number field element but which allows the appropriate symbolic operations.
</p>
TicketrwsSun, 26 Jun 2016 15:28:38 GMT
https://trac.sagemath.org/ticket/18036#comment:34
https://trac.sagemath.org/ticket/18036#comment:34
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/18036#comment:33" title="Comment 33">jdemeyer</a>:
</p>
<blockquote class="citation">
<p>
Ideally, <code>I</code> should be some number field element but which allows the appropriate symbolic operations.
</p>
</blockquote>
<p>
Well, if the operation's name is a registered function
, convert to symbolic, apply, convert back?
</p>
TicketkcrismanFri, 20 Jan 2017 01:55:45 GMT
https://trac.sagemath.org/ticket/18036#comment:35
https://trac.sagemath.org/ticket/18036#comment:35
<p>
See also <a class="closed ticket" href="https://trac.sagemath.org/ticket/22208" title="enhancement: Conversion from SR to number fields (closed: fixed)">#22208</a>.
</p>
TicketrwsMon, 20 Feb 2017 07:20:41 GMTbranch changed
https://trac.sagemath.org/ticket/18036#comment:36
https://trac.sagemath.org/ticket/18036#comment:36
<ul>
<li><strong>branch</strong>
changed from <em>u/jdemeyer/i_parent___should_not_be_the_symbolic_ring</em> to <em>public/18036</em>
</li>
</ul>
TicketgitSun, 04 Mar 2018 15:21:54 GMTcommit changed
https://trac.sagemath.org/ticket/18036#comment:37
https://trac.sagemath.org/ticket/18036#comment:37
<ul>
<li><strong>commit</strong>
changed from <em>2f5a5198849c5b96bc2733e1e5853dc1b23f1cf9</em> to <em>d7fab0b6a8628301543ed7bfae70380e1d6fa714</em>
</li>
</ul>
<p>
Branch pushed to git repo; I updated commit sha1. New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit/?id=d7fab0b6a8628301543ed7bfae70380e1d6fa714"><span class="icon"></span>d7fab0b</a></td><td><code>Merge branch 'develop' into t/18036/public/18036</code>
</td></tr></table>
Ticket