Sage: Ticket #24939: solve should not convert floating point to rationals when solving
https://trac.sagemath.org/ticket/24939
<p>
The following (obtained on 8.2.beta6) is very bad
</p>
<pre class="wiki">sage: solve(1.0 * x^2 - 1.5*x + 2.0, x)
[x == -1/4*I*sqrt(23) + 3/4, x == 1/4*I*sqrt(23) + 3/4]
</pre><p>
The input is an equation with floating point numbers (likely to be approximations). The answer obtained are exact symbolic expressions... it becomes crazy with
</p>
<pre class="wiki">sage: solve(1.13157771r * x^2 - 1.2241351312r*x + 2.0000401231r, x)
[x == -1/1516050631807733202922*I*sqrt(3389945193423588592231412963046087595757907) + 190736613975697/352629861450338,
x == 1/1516050631807733202922*I*sqrt(3389945193423588592231412963046087595757907) + 190736613975697/352629861450338]
</pre>en-usSagehttps://trac.sagemath.org/chrome/site/logo_sagemath_trac.png
https://trac.sagemath.org/ticket/24939
Trac 1.1.6vdelecroixSat, 10 Mar 2018 10:01:14 GMTdescription changed
https://trac.sagemath.org/ticket/24939#comment:1
https://trac.sagemath.org/ticket/24939#comment:1
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/24939?action=diff&version=1">diff</a>)
</li>
</ul>
TicketrwsSat, 10 Mar 2018 13:52:25 GMTpriority changed
https://trac.sagemath.org/ticket/24939#comment:2
https://trac.sagemath.org/ticket/24939#comment:2
<ul>
<li><strong>priority</strong>
changed from <em>major</em> to <em>minor</em>
</li>
</ul>
<p>
We are following Maxima's lead here:
</p>
<pre class="wiki">(%i3) solve(1.0 * x^2 - 1.5*x + 2.0, x);
rat: replaced 2.0 by 2/1 = 2.0
rat: replaced -1.5 by -3/2 = -1.5
rat: replaced 1.0 by 1/1 = 1.0
sqrt(23) %i - 3 sqrt(23) %i + 3
(%o3) [x = - ---------------, x = ---------------]
4 4
</pre><p>
Note that our documentation states: <code>Whenever possible, answers will be symbolic, but with systems of equations, at times approximations will be given by Maxima, due to the underlying algorithm</code>.
</p>
<p>
The workaround would be to use SymPy:
</p>
<pre class="wiki">sage: solve(1.0 * x^2 - 1.5*x + 2.0, x, algorithm='sympy')
[x == (0.750000000000000 - 1.19895788082818*I),
x == (0.750000000000000 + 1.19895788082818*I)]
sage: solve(1.13157771r * x^2 - 1.2241351312r*x + 2.0000401231r, x, algorithm='s
....: ympy')
[x == (0.540897509902347 - 1.21445837087478*I),
x == (0.540897509902347 + 1.21445837087478*I)]
</pre>
TicketvdelecroixSat, 10 Mar 2018 13:55:48 GMT
https://trac.sagemath.org/ticket/24939#comment:3
https://trac.sagemath.org/ticket/24939#comment:3
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/24939#comment:2" title="Comment 2">rws</a>:
</p>
<blockquote class="citation">
<p>
We are following Maxima's lead here:
</p>
<pre class="wiki"><SNIP>
</pre><p>
Note that our documentation states: <code>Whenever possible, answers will be symbolic, but with systems of equations, at times approximations will be given by Maxima, due to the underlying algorithm</code>.
</p>
</blockquote>
<p>
Though it make no sense in the present situation! And the meaning of "symbolic" is anyway very vague.
</p>
<blockquote class="citation">
<p>
The workaround would be to use SymPy:
</p>
<pre class="wiki"><SNIP>
</pre></blockquote>
<p>
Much better :-)
</p>
TicketrwsSat, 10 Mar 2018 13:59:03 GMT
https://trac.sagemath.org/ticket/24939#comment:4
https://trac.sagemath.org/ticket/24939#comment:4
<p>
Finally, see polynomial_element.pyx the roots() member where I inserted fast code that avoids calling Maxima for degree 2. I would be interested in taking over solving every polynomial that's possible in Pynac if I had support for it. It would make QQbar faster, because QQbar uses that code in roots() too.
</p>
TicketvdelecroixSat, 10 Mar 2018 15:17:38 GMT
https://trac.sagemath.org/ticket/24939#comment:5
https://trac.sagemath.org/ticket/24939#comment:5
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/24939#comment:4" title="Comment 4">rws</a>:
</p>
<blockquote class="citation">
<p>
Finally, see polynomial_element.pyx the roots() member where I inserted fast code that avoids calling Maxima for degree 2. I would be interested in taking over solving every polynomial that's possible in Pynac if I had support for it. It would make QQbar faster, because QQbar uses that code in roots() too.
</p>
</blockquote>
<p>
This code in <code>polynomial_element.pyx</code> is numerically unstable. You should not try to reinvent the wheel here
</p>
<pre class="wiki">sage: coeffs = [85.37r, -59.22r, 10.27r]
sage: RDFx = RDF['x']
sage: pRDF = RDFx(coeffs)
sage: r1, r2 = pRDF.roots(multiplicities=False)
sage: coeffs[2] * r1^2 + coeffs[1] * r1 + coeffs[0]
0.0
</pre><p>
the same with SR
</p>
<pre class="wiki">sage: coeffs = [85.37r, -59.22r, 10.27r]
sage: SRx = SR['x']
sage: pSR = SRx(coeffs)
sage: r1, r2 = pSR.roots(multiplicities=False)
sage: coeffs[2] * r1^2 + coeffs[1] * r1 + coeffs[0]
1.4210854715202004e-14
</pre><p>
Moreover having <code>import SR</code> any time <code>roots</code> is called is slowing down everything and is a very bad practice. You should have used the special method <code>_roots_univariate_polynomial</code> that has to be implemented directly into the ring. See <a class="needs_work ticket" href="https://trac.sagemath.org/ticket/24942" title="defect: move roots solving of univariate SR polynomial ring (needs_work)">#24942</a>.
</p>
TicketvdelecroixSat, 10 Mar 2018 15:20:34 GMT
https://trac.sagemath.org/ticket/24939#comment:6
https://trac.sagemath.org/ticket/24939#comment:6
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/24939#comment:5" title="Comment 5">vdelecroix</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/24939#comment:4" title="Comment 4">rws</a>:
Moreover having <code>import SR</code> any time <code>roots</code> is called is slowing down everything and is a very bad practice. You should have used the special method <code>_roots_univariate_polynomial</code> that has to be implemented directly into the ring. See <a class="needs_work ticket" href="https://trac.sagemath.org/ticket/24942" title="defect: move roots solving of univariate SR polynomial ring (needs_work)">#24942</a>.
</p>
</blockquote>
<p>
To be clear: anything specific to <code>SR</code> has to go in <code>symbolic/</code> and not invade the whole Sage code. This code was badly intrusive.
</p>
TicketrwsSat, 10 Mar 2018 15:59:56 GMT
https://trac.sagemath.org/ticket/24939#comment:7
https://trac.sagemath.org/ticket/24939#comment:7
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/24939#comment:6" title="Comment 6">vdelecroix</a>:
</p>
<blockquote class="citation">
<p>
To be clear: anything specific to <code>SR</code> has to go in <code>symbolic/</code> and not invade the whole Sage code. This code was badly intrusive.
</p>
</blockquote>
<p>
To be clear as well: that specialization was not introduced by me. I merely added a shortcut that no longer used Maxima.
</p>
TicketvdelecroixSat, 10 Mar 2018 16:04:53 GMT
https://trac.sagemath.org/ticket/24939#comment:8
https://trac.sagemath.org/ticket/24939#comment:8
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/24939#comment:7" title="Comment 7">rws</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/24939#comment:6" title="Comment 6">vdelecroix</a>:
</p>
<blockquote class="citation">
<p>
To be clear: anything specific to <code>SR</code> has to go in <code>symbolic/</code> and not invade the whole Sage code. This code was badly intrusive.
</p>
</blockquote>
<p>
To be clear as well: that specialization was not introduced by me. I merely added a shortcut that no longer used Maxima.
</p>
</blockquote>
<p>
Actually, this is not only true for <code>SR</code> but for some other rings as well! This <code>roots</code> code is a mess...
</p>
TicketrwsSun, 25 Mar 2018 05:56:32 GMT
https://trac.sagemath.org/ticket/24939#comment:9
https://trac.sagemath.org/ticket/24939#comment:9
<p>
Coming back to the original problem the solution would be to insert a shortcut for inexact polynomial input in solve that uses other methods. The default <code>algorithm</code> of solve at the moment is Maxima so the documentation should explain that with such input other methods are used. Specifically, I would not try to implement this by turning a switch on/off in Maxima because Sage's own root finding methods are probably better suited for all the possible inexact Sage number types.
</p>
TicketrwsSun, 25 Mar 2018 05:59:04 GMT
https://trac.sagemath.org/ticket/24939#comment:10
https://trac.sagemath.org/ticket/24939#comment:10
<p>
See <code>Expression.is_exact()</code>.
</p>
Ticket