Sage: Ticket #6862: Mixing of different domains for symbolic variables
https://trac.sagemath.org/ticket/6862
<p>
From suge-support
</p>
<p>
On Sep 1, 11:35 pm, Mani chandra <mchan...@…> wrote:
</p>
<blockquote class="citation">
<p>
Mani chandra wrote:
</p>
</blockquote>
<pre class="wiki">sage: x = a + I*b
sage: real(x.conjugate().simplify())
real_part(a) + imag_part(b)
sage: real(x.conjugate())
real_part(a) - imag_part(b)
</pre><p>
This seems to be happening because maxima(via simplify)
treats variables as real whereas pynac treats as
complex.
</p>
<pre class="wiki">sage: x.conjugate()
conjugate(a) - I*conjugate(b)
sage: x.conjugate().simplify()
a - I*b
</pre>en-usSagehttps://trac.sagemath.org/chrome/site/logo_sagemath_trac.png
https://trac.sagemath.org/ticket/6862
Trac 1.1.6kcrismanFri, 04 Sep 2009 18:04:17 GMT
https://trac.sagemath.org/ticket/6862#comment:1
https://trac.sagemath.org/ticket/6862#comment:1
<p>
See <a class="ext-link" href="http://groups.google.com/group/sage-devel/browse_thread/thread/e25e03c9dba88a93"><span class="icon"></span>http://groups.google.com/group/sage-devel/browse_thread/thread/e25e03c9dba88a93</a>
</p>
<p>
Also, based on the hint there from Robert Dodier, here is the eventual way a fix will have to occur, perhaps as outlined in the thread:
</p>
<pre class="wiki">sage: assume(a,'complex')
sage: x.conjugate().simplify()
-I*b + conjugate(a)
</pre>
TicketkcrismanSun, 24 Feb 2013 02:19:43 GMTupstream set
https://trac.sagemath.org/ticket/6862#comment:2
https://trac.sagemath.org/ticket/6862#comment:2
<ul>
<li><strong>upstream</strong>
set to <em>N/A</em>
</li>
</ul>
<p>
See also this closely related <a class="ext-link" href="http://ask.sagemath.org/question/2287/bug-with-absolute-value-of-a-complex-variable"><span class="icon"></span>ask.sagemath.org question</a>, where the following example occurs.
</p>
<pre class="wiki">sage: var('a')
a
sage: b=a*a.conjugate()-a*a
sage: b
-a^2 + a*conjugate(a)
sage: simplify(b)
0
</pre><p>
I think this is a little weird, though, since in Maxima
</p>
<pre class="wiki">(%i1) domain:complex;
(%o1) complex
(%i2) -a^2+a*conjugate(a);
(%o2) 0
</pre><p>
and sadly, the Maxima manual says that all this is expected to do is
</p>
<pre class="wiki">Option variable: domain
Default value: real
When domain is set to complex, sqrt (x^2) will remain sqrt (x^2) instead of returning abs(x).
</pre><p>
William says in the thread above that
</p>
<pre class="wiki">What we need is to queue up (put in some list somewhere) all
declaration that could ever be needed, then whenever we do a Sage -->
calculus Maxima conversion, we would empty the queue if it is
nonempty. Also, if Maxima were to crash/get restarted (does that ever
happen anymore), we would need to make sure all var's get set again.
This seems very do-able.
</pre><p>
and perhaps that could be part of the initialization process of any variable - without actually calling Maxima at that time, of course!
</p>
TicketkcrismanThu, 13 Jun 2013 16:13:56 GMT
https://trac.sagemath.org/ticket/6862#comment:3
https://trac.sagemath.org/ticket/6862#comment:3
<p>
<a class="new ticket" href="https://trac.sagemath.org/ticket/14628" title="defect: Zero solution does not result in zero (new)">#14628</a> is somewhat related, though this would not fix it, as far as I can tell.
</p>
TicketkcrismanThu, 13 Jun 2013 16:15:38 GMT
https://trac.sagemath.org/ticket/6862#comment:4
https://trac.sagemath.org/ticket/6862#comment:4
<p>
Let's make sure to also test <a class="closed ticket" href="https://trac.sagemath.org/ticket/11656" title="defect: Imaginary part of symbolic variable disappears in simplify_full() (closed: duplicate)">#11656</a>, which was a dup, when (?!) we fix this:
</p>
<pre class="wiki">var('c', domain='complex')
var('x', domain='real')
C = c * exp(-x^2)
print (C)
c*e^(-x^2)
print (C.imag())
e^(-x^2)*imag_part(c)
print (C.imag().simplify_full())
0
</pre>
TicketzimmermaThu, 29 Aug 2013 07:49:40 GMT
https://trac.sagemath.org/ticket/6862#comment:5
https://trac.sagemath.org/ticket/6862#comment:5
<p>
see also <a class="closed ticket" href="https://trac.sagemath.org/ticket/14305" title="defect: Doctest: Immediate simplifications of symbolic powers (closed: fixed)">#14305</a>
</p>
<p>
Paul
</p>
TicketkcrismanThu, 08 Oct 2020 12:47:07 GMTpriority changed
https://trac.sagemath.org/ticket/6862#comment:6
https://trac.sagemath.org/ticket/6862#comment:6
<ul>
<li><strong>priority</strong>
changed from <em>critical</em> to <em>major</em>
</li>
</ul>
<p>
See <a class="ext-link" href="https://groups.google.com/forum/#!topic/sage-devel/U1dsVFP-2PA"><span class="icon"></span>https://groups.google.com/forum/#!topic/sage-devel/U1dsVFP-2PA</a>
</p>
TicketcharpentSat, 13 Mar 2021 13:44:28 GMTstatus changed; milestone set
https://trac.sagemath.org/ticket/6862#comment:7
https://trac.sagemath.org/ticket/6862#comment:7
<ul>
<li><strong>status</strong>
changed from <em>new</em> to <em>needs_review</em>
</li>
<li><strong>milestone</strong>
set to <em>sage-duplicate/invalid/wontfix</em>
</li>
</ul>
<p>
The result reported in the description is correct :
</p>
<pre class="wiki">sage: var("a, b")
(a, b)
sage: c=a+I*b
sage: c.real()
-imag_part(b) + real_part(a)
sage: c.conjugate()
conjugate(a) - I*conjugate(b)
sage: c.conjugate().real()
-imag_part(b) + real_part(a)
</pre><p>
<em>unless <code>a</code> and <code>b</code> are <strong>known</strong> to be real}}}</em>. If so :
</p>
<pre class="wiki">sage: assume(a, b, "real")
sage: c.real()
a
sage: c.conjugate()
a - I*b
sage: c.conjugate().real()
a
</pre><p>
which is also correct.
</p>
<p>
==> marking as invalid and requesting review in order to get this bug closed...
</p>
TicketkcrismanSat, 13 Mar 2021 22:04:56 GMTstatus, priority, milestone changed
https://trac.sagemath.org/ticket/6862#comment:8
https://trac.sagemath.org/ticket/6862#comment:8
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_work</em>
</li>
<li><strong>priority</strong>
changed from <em>major</em> to <em>minor</em>
</li>
<li><strong>milestone</strong>
changed from <em>sage-duplicate/invalid/wontfix</em> to <em>sage-9.4</em>
</li>
</ul>
<p>
The problem is Maxima, not Sage. (Or rather, the fact that we don't have a good way to make sure that Maxima variables are complex by default, or didn't at the time.)
</p>
<pre class="wiki">sage: real(x.conjugate().simplify())
real_part(a) + imag_part(b)
</pre>
TicketcharpentSat, 13 Mar 2021 22:38:18 GMTstatus, milestone changed
https://trac.sagemath.org/ticket/6862#comment:9
https://trac.sagemath.org/ticket/6862#comment:9
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>needs_review</em>
</li>
<li><strong>milestone</strong>
changed from <em>sage-9.4</em> to <em>sage-duplicate/invalid/wontfix</em>
</li>
</ul>
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/6862#comment:8" title="Comment 8">kcrisman</a>:
</p>
<blockquote class="citation">
<p>
The problem is Maxima, not Sage. (Or rather, the fact that we don't have a good way to make sure that Maxima variables are complex by default, or didn't at the time.)
</p>
<pre class="wiki">sage: real(x.conjugate().simplify())
real_part(a) + imag_part(b)
</pre></blockquote>
<p>
Unless <code>a</code> and <code>b</code> are known to be real, this is the correct result. When this assumption is verifiable, Sage also gives the expected result (see comment 7)...
</p>
<p>
BTW, at least the "Computational mathematics with <a class="wiki" href="https://trac.sagemath.org/wiki/SageMath">SageMath</a>" book states that SR variables behave, by default, as complex variables, but, IIRC, no formal assertion is made in the documentation about this. AFAICT, we use a"domain:complex" assertion in our uses of Maxima.
</p>
<p>
So what should be the behavior you expect ? OIn fact, I'm having troubleperceivng the point of this ticket...
</p>
<p>
==> re-asking review ; possibly after discussion on <code>sage-devel</code> if we can't agree...
</p>
TicketkcrismanSun, 14 Mar 2021 02:44:24 GMTstatus changed
https://trac.sagemath.org/ticket/6862#comment:10
https://trac.sagemath.org/ticket/6862#comment:10
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_work</em>
</li>
</ul>
<blockquote class="citation">
<blockquote class="citation">
<pre class="wiki">sage: real(x.conjugate().simplify())
real_part(a) + imag_part(b)
</pre></blockquote>
</blockquote>
<p>
I thought you said this one was correct:
</p>
<pre class="wiki">sage: c.conjugate().real()
-imag_part(b) + real_part(a)
</pre><p>
So you can see that the Maxima (<code>.simplify()</code>) and Sage result are different, unless I'm even more confused.
</p>
<blockquote class="citation">
<p>
BTW, at least the "Computational mathematics with <a class="wiki" href="https://trac.sagemath.org/wiki/SageMath">SageMath</a>" book states that SR variables behave, by default, as complex variables, but, IIRC, no formal assertion is made in the documentation about this. AFAICT, we use a"domain:complex" assertion in our uses of Maxima.
</p>
</blockquote>
<p>
The problem is that <code>domain:complex</code> doesn't make the Maxima variables complex, it just doesn't simplify square roots (see the linked sage-devel thread in <a class="ticket" href="https://trac.sagemath.org/ticket/6862#comment:1" title="Comment 1">comment:1</a>). We do use complex variables for <code>SR</code> but those live in Pynac. However, since <code>.simplify()</code> is a Sage method (it just sends to Maxima and back), we don't want that giving wrong behavior.
</p>
<p>
Anyway, perhaps we need a third party to adjudicate; I did try to suss out the right behavior after your <a class="ticket" href="https://trac.sagemath.org/ticket/6862#comment:7" title="Comment 7">comment:7</a> but I have been known to make sign errors in my life :-) But I hope I clarified the exact status in this comment.
</p>
<pre class="wiki">var("a, b")
c=a+I*b
print(c.conjugate().real())
print((c.conjugate().simplify()).real())
</pre><p>
<a class="ext-link" href="https://sagecell.sagemath.org/?z=eJwrSyzSUErUUUhS0uTlSrZN1PbUSuLlUk7WK0pNzNHQBDOT8_OyStMTS1JB_IKizLwSDRRBqFq4JJpscWZuQU5mWiVQBUwlAOCYI5M=&lang=sage&interacts=eJyLjgUAARUAuQ=="><span class="icon"></span>gives</a>
</p>
<pre class="wiki">-imag_part(b) + real_part(a)
imag_part(b) + real_part(a)
</pre><p>
and I don't think those can both be correct.
</p>
TicketnbruinSun, 14 Mar 2021 20:39:53 GMT
https://trac.sagemath.org/ticket/6862#comment:11
https://trac.sagemath.org/ticket/6862#comment:11
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/6862#comment:10" title="Comment 10">kcrisman</a>:
</p>
<blockquote class="citation">
<p>
Anyway, perhaps we need a third party to adjudicate; I did try to suss out the right behavior after your <a class="ticket" href="https://trac.sagemath.org/ticket/6862#comment:7" title="Comment 7">comment:7</a> but I have been known to make sign errors in my life :-) But I hope I clarified the exact status in this comment.
</p>
<pre class="wiki">var("a, b")
c=a+I*b
print(c.conjugate().real())
print((c.conjugate().simplify()).real())
</pre><p>
<a class="ext-link" href="https://sagecell.sagemath.org/?z=eJwrSyzSUErUUUhS0uTlSrZN1PbUSuLlUk7WK0pNzNHQBDOT8_OyStMTS1JB_IKizLwSDRRBqFq4JJpscWZuQU5mWiVQBUwlAOCYI5M=&lang=sage&interacts=eJyLjgUAARUAuQ=="><span class="icon"></span>gives</a>
</p>
<pre class="wiki">-imag_part(b) + real_part(a)
imag_part(b) + real_part(a)
</pre><p>
and I don't think those can both be correct.
</p>
</blockquote>
<p>
Indeed; I'd say that the problem diagnosed in the ticket is spot on. I also don't know what the best solution is. Note that the two results are both correct if <code>imag_part(b)==0</code>, which is what maxima assumes (and we inherit those assumptions by the implementation of <code>simplify</code>).
</p>
<p>
A minimal solution would be to document (in simplify and/or in real_part, imag_part, and conjugate) that for <code>simplify</code>, symbolic variables are assumed to be real, so that <code>conjugate(x).simplify()==real_part(x).simplify()==x</code> and <code>imag_part(x).simplify()==0</code>.
</p>
TicketcharpentSun, 14 Mar 2021 22:02:34 GMT
https://trac.sagemath.org/ticket/6862#comment:12
https://trac.sagemath.org/ticket/6862#comment:12
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/6862#comment:11" title="Comment 11">nbruin</a>:
</p>
<p>
[ Snip... ]
</p>
<blockquote class="citation">
<p>
Indeed; I'd say that the problem diagnosed in the ticket is spot on.
</p>
</blockquote>
<p>
Indeed...
</p>
<blockquote class="citation">
<p>
I also don't know what the best solution is. Note that the two results are both correct if <code>imag_part(b)==0</code>, which is what maxima assumes (and we inherit those assumptions by the implementation of <code>simplify</code>).
</p>
<p>
A minimal solution would be to document (in simplify and/or in real_part, imag_part, and conjugate) that for <code>simplify</code>, symbolic variables are assumed to be real, so that <code>conjugate(x).simplify()==real_part(x).simplify()==x</code> and <code>imag_part(x).simplify()==0</code>.
</p>
</blockquote>
<p>
At the (accepted) risk of lampooning the British Commons : No, no, no, no, no, no, no, no.
</p>
<p>
And no...
</p>
<p>
This assumption is a way too large limitation of Sage's algebraic abilities. And can't be enforced by checks...
</p>
<p>
Finding the source of the problem is necessary. It might help to show that the problem is alleviated by <em>renaming</em> the variables :
</p>
<pre class="wiki">sage: %cpaste
Pasting code; enter '--' alone on the line to stop or use Ctrl-D.
:var('a,b')
:c=a+I*b
:L=c.operands()
:aL=[maxima.gensym().sage() for u in L]
:D=dict(zip(L,aL))
:DI=dict(zip(aL,L))
:print(c.conjugate().real())
:print(c.conjugate().simplify().real())
:print(c.subs(D).conjugate().real().subs(DI))
:print(c.subs(D).conjugate().simplify().real().subs(DI))
:--
(a, b)
-imag_part(b) + real_part(a)
imag_part(b) + real_part(a)
-imag_part(b) + real_part(a)
-imag_part(b) + real_part(a)
</pre><p>
However :
</p>
<pre class="wiki">sage: print(c.conjugate().subs(D).simplify().real().subs(DI))
imag_part(b) + real_part(a)
</pre><p>
This behaviour let us think that somehow, <code>simplify</code> doesn't account for the "complexity"of <code>(-I*b")</code>. Another hint in this direction :
</p>
<pre class="wiki">sage: with assuming(a,b,"real"):c.conjugate().simplify().real()
a
sage: with assuming(a,b,"complex"):c.conjugate().simplify().real()
-imag_part(b) + real_part(a)
</pre><p>
which is correct.
</p>
<p>
This suggests a direction for debugging the source (which is probably in <code>pynac</code> territory, i. e. put of my reach...) and a possible workaround : bracket calls to Maxima's <code>simplify</code> with an explicit assumption of complexity for all variables not declared otherwise... This is problematic, however, since <code>simplify</code> just converts its argument to Maxima and back. Following the relevant code isn't exactly easy...
</p>
<p>
However, the real problem is probably not in Maxima itself :
</p>
<pre class="wiki">(%i1) display2d:false;
(%o1) false
(%i2) domain:complex;
(%o2) complex
(%i3) c:a+%i*b;
(%o3) %i*b+a
(%i4) realpart(conjugate(c));
(%o4) a
(%i5) realpart(ratsimp(conjugate(c)));
(%o5) a
</pre><p>
Notwithstanding the <code>domain</code> setting, Maxima acts as if <code>a</code> and <code>b</code> were real.
</p>
<pre class="wiki">(%i6) declare(a, complex, b, complex);
(%o6) done
(%i7) realpart(conjugate(c));
(%o7) 'realpart(a)-'imagpart(b)
(%i8) realpart(ratsimp(conjugate(c)));
(%o8) 'realpart(a)-'imagpart(b)
</pre><p>
Maxima's <code>ratsimp</code> does not create the same problem as Sage`s <code>simplify</code>.
</p>
<p>
HTH,
</p>
TicketnbruinSun, 14 Mar 2021 22:38:52 GMT
https://trac.sagemath.org/ticket/6862#comment:13
https://trac.sagemath.org/ticket/6862#comment:13
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/6862#comment:12" title="Comment 12">charpent</a>:
</p>
<blockquote class="citation">
<p>
This behaviour let us think that somehow, <code>simplify</code> doesn't account for the "complexity"of <code>(-I*b")</code>. Another hint in this direction :
</p>
<pre class="wiki">sage: with assuming(a,b,"real"):c.conjugate().simplify().real()
a
sage: with assuming(a,b,"complex"):c.conjugate().simplify().real()
-imag_part(b) + real_part(a)
</pre><p>
which is correct.
</p>
</blockquote>
<p>
Nice find! That is consistent with "maxima by default assumes variables are real-valued as far as conjugate, real_part, imag_part as concerned", so there's a mismatch between sage/pynac and maxima what the default assumptions about variables is, and indeed the appropriate work-around is to sync up those assumptions to match (one way or the other).
</p>
<p>
I'm not so sure if we should bracket each simplify call with an <code>assume</code>. I think it's the responsibility of the interface to translate <code>x</code> into a symbol in the other system with the right properties. So I think that <code>maxima_calculus(x)</code> should basically already insert the assumption on the maxima side, unless <code>x</code> is assumed to be <code>real</code>: mismatching defaults on the maxima side just mean we cannot rely on the default behaviour there and we need to enforce the desired behaviour appropriately.
</p>
<p>
I'd also be fine with changing the assumption that variables are by default real unless declared otherwise. If we want to change our default assumption about variables, we may need to change pynac. Otherwise, I think it's a matter of changing the maxima interface (mainly the maxima_calculus one).
</p>
TicketkcrismanMon, 15 Mar 2021 01:57:00 GMT
https://trac.sagemath.org/ticket/6862#comment:14
https://trac.sagemath.org/ticket/6862#comment:14
<blockquote class="citation">
<p>
Nice find! That is consistent with "maxima by default assumes variables are real-valued as far as conjugate, real_part, imag_part as concerned",
</p>
</blockquote>
<p>
Correct. As I mention above, <code>domain:complex</code> is useful but doesn't affect much beyond <code>sqrt</code>. And I doubt Maxima will be changing that.
</p>
<blockquote class="citation">
<p>
I'm not so sure if we should bracket each simplify call with an <code>assume</code>. I think it's the responsibility of the interface to translate <code>x</code> into a symbol in the other system with the right properties. So I think that <code>maxima_calculus(x)</code> should basically already insert the assumption on the maxima side, unless <code>x</code> is assumed to be <code>real</code>: mismatching defaults on the maxima side just mean we cannot rely on the default behaviour there and we need to enforce the desired behaviour appropriately.
</p>
</blockquote>
<p>
Yes, we should be sending the correct thing to Maxima. The problem is that it might be hard to parse out every symbol and make sure it has all the right extra assumptions, or at least in the past that seems to have led into a rat's nest. We do prepend <code>sage_var</code> or something like that to each Sage variable in Maxima, so at least in theory it should be possible, but one wouldn't want to overwrite previous assumptions, so a lot of testing would be involved. It would be really nice, of course!
</p>
<blockquote class="citation">
<p>
I'd also be fine with changing the assumption that variables are by default real unless declared otherwise. If we want to change our default assumption about variables, we may need to change pynac.
</p>
</blockquote>
<p>
I think that changing all variables to real by default probably would be a bad move in many ways. (I don't think you're suggesting that, but the way you phrased it sounds like that.)
</p>
TicketcharpentMon, 15 Mar 2021 10:18:01 GMTmilestone, upstream changed
https://trac.sagemath.org/ticket/6862#comment:15
https://trac.sagemath.org/ticket/6862#comment:15
<ul>
<li><strong>milestone</strong>
changed from <em>sage-duplicate/invalid/wontfix</em> to <em>sage-9.3</em>
</li>
<li><strong>upstream</strong>
changed from <em>N/A</em> to <em>Reported upstream. No feedback yet.</em>
</li>
</ul>
<p>
The <code>Maxima</code> problem has been <a class="ext-link" href="https://sourceforge.net/p/maxima/bugs/3747/"><span class="icon"></span>reported</a> upstream.
</p>
TicketcharpentMon, 15 Mar 2021 10:20:11 GMTpriority changed
https://trac.sagemath.org/ticket/6862#comment:16
https://trac.sagemath.org/ticket/6862#comment:16
<ul>
<li><strong>priority</strong>
changed from <em>minor</em> to <em>critical</em>
</li>
</ul>
<p>
Priority set to <code>critical</code> because this bug silenty leads to mathematically incorrect results.
</p>
TicketnbruinMon, 15 Mar 2021 17:31:55 GMT
https://trac.sagemath.org/ticket/6862#comment:17
https://trac.sagemath.org/ticket/6862#comment:17
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/6862#comment:14" title="Comment 14">kcrisman</a>:
</p>
<blockquote class="citation">
<p>
Yes, we should be sending the correct thing to Maxima. The problem is that it might be hard to parse out every symbol and make sure it has all the right extra assumptions, or at least in the past that seems to have led into a rat's nest. We do prepend <code>sage_var</code> or something like that to each Sage variable in Maxima, so at least in theory it should be possible, but one wouldn't want to overwrite previous assumptions, so a lot of testing would be involved. It would be really nice, of course!
</p>
</blockquote>
<p>
That should actually be dead-easy. This is not about sending strings over that need to be parsed for variables; this is about sending expressions over. They are already parsed. Especially if you do that in the way that maxima_lib works, the symbol needs to be created on the maxima side. If we assume our variables to be complex by default, then that assumption should be inserted at that time. If assumptions change, we just need to do whatever dance we do already to change them on the maxima side as well.
</p>
<p>
The main problem I expect is that inserting the assumption will probably lead to other side-effects we didn't anticipate. That's why I figured documenting the current "simplify" behaviour is the easier way out (but I wouldn't trust non-trivial SR computations for publication-quality work anyway).
</p>
TicketkcrismanMon, 15 Mar 2021 17:35:25 GMT
https://trac.sagemath.org/ticket/6862#comment:18
https://trac.sagemath.org/ticket/6862#comment:18
<blockquote class="citation">
<p>
That should actually be dead-easy. This is not about sending strings over that need to be parsed for variables; this is about sending expressions over. They are already parsed. Especially if you do that in the way that maxima_lib works, the symbol needs to be created on the maxima side. If we assume our variables to be complex by default, then that assumption should be inserted at that time. If assumptions change, we just need to do whatever dance we do already to change them on the maxima side as well.
</p>
</blockquote>
<p>
Good. And I certainly only care about the <code>maxima_lib</code> case.
</p>
<blockquote class="citation">
<p>
The main problem I expect is that inserting the assumption will probably lead to other side-effects we didn't anticipate. That's why I figured documenting the current "simplify" behaviour is the easier way out (but I wouldn't trust non-trivial SR computations for publication-quality work anyway).
</p>
</blockquote>
<p>
True.
</p>
<blockquote class="citation">
<p>
The Maxima problem has been reported upstream.
</p>
</blockquote>
<p>
I expect they will say this is user error or won't implement, since the documentation makes it pretty clear that <code>domain:complex</code> doesn't do much, and presumably (though by implication only) shouldn't be expected to do much else.
</p>
TicketcharpentSun, 21 Mar 2021 08:56:07 GMTupstream changed
https://trac.sagemath.org/ticket/6862#comment:19
https://trac.sagemath.org/ticket/6862#comment:19
<ul>
<li><strong>upstream</strong>
changed from <em>Reported upstream. No feedback yet.</em> to <em>Reported upstream. Developers deny it's a bug.</em>
</li>
</ul>
<p>
According to <a class="ext-link" href="https://sourceforge.net/p/maxima/bugs/3747/#fe49"><span class="icon"></span>Stavros Macrakis</a>,<code>domain</code> is supposed to have an effect only for power operations (and is not expected to have an effect on <code>realpart</code>). He reclassified the issue as a documentation issue (wrongly, IMHO, but nothing can be done...).
</p>
<p>
We should therefore fox it at Sage's level...
</p>
Ticketgh-DaveWitteMorrisSun, 28 Mar 2021 22:42:46 GMT
https://trac.sagemath.org/ticket/6862#comment:20
https://trac.sagemath.org/ticket/6862#comment:20
<p>
Related ticket: <a class="new ticket" href="https://trac.sagemath.org/ticket/30793" title="defect: Sage may ignore the imaginary part of variables not explicitly ... (new)">#30793</a>.
</p>
Ticket