# Revision history [back]

My answer has two parts. First, I show you what happens (there is bug that should be corrected!). I am not able to fully explain why this happens (maybe a quite recent change in Maxima, but maybe not...). Then I give you a workaround (that is better to use I think even when the bug will be removed).

Let me denote by $p$ your degree-$12$ polynomial, and by $q$ the degree-$10$ polynomial. The command you typed makes a call to the software Maxima. It happens that Maxima is able to find the approximate roots of $p$, and returns something like [[x == -1.99194847020934], [x == -1.927925665494726], ..., [x == 1.967859308671922]] (though in its own language), and Sage correctly transforms it to its representation. Everything's fine! For $q$, Maxima is unable to solve it (I do not know why) and returns something like [0 == 2*x^5 - 10*x^3 + 10*x + sqrt(5) + 1, 0 == 2*x^5 - 10*x^3 + 10*x - sqrt(5) + 1]. But the problem is as follows: Sage expects that Maxima raises an error when it is unable to find explicit solutions. This is apparently not the case! (Here, this may come from a change in Maxima, I have to investigate further.) So since there is no error from Maxima, Sage thinks that Maxima returned explicit solutions and tries to convert. This is where the IndexError appears since the answer from Maxima has not the required form.

For your problem, there are alternative methods to use, that are better to my mind – that is faster, safer, with better error guarantees. You first declare a polynomial ring in x over the integers and the polynomial you want to work with:

sage: R.<x> = ZZ[]
sage: q = x^10 - 10*x^8 + 35*x^6 + x^5 - 50*x^4 - 5*x^3 + 25*x^2 + 5*x - 1


Then you can ask for the roots of your polynomials in RR which is the floating-point representation of the real numbers, or in AA which is the field of (exactly-represented) algebraic real numbers:

sage: q.roots(RR)
[(-1.98422940262896, 1),
(-1.85955297177650, 1),
(-1.27484797949738, 1),
(-0.851558583130145, 1),
(-0.374762629171449, 1),
(0.125581039058627, 1),
(1.07165358995799, 1),
(1.45793725484282, 1),
(1.75261336008773, 1),
(1.93716632225726, 1)]
sage: q.roots(AA, multiplicities=False)
[-1.984229402628956?,
-1.859552971776503?,
-1.274847979497380?,
-0.8515585831301453?,
-0.3747626291714493?,
0.1255810390586268?,
1.071653589957994?,
1.457937254842823?,
1.752613360087728?,
1.937166322257263?]


Note that though you only see a finite number of decimals in the case of AA, roots are actually exactly represented as algebraic numbers, meaning that you can ask for as many decimals as you want and they will always be correct:

sage: r = q.roots(AA, multiplicities=False)[0]
sage: RR(r) # 53 bits of precision
-1.98422940262896
sage: RealField(500)(r) # 500 bits of precision
-1.98422940262895566209958608557155704290607341793759147174204245282176622450543068323073533550690797129244633009657456338304984019241338312932708655898


My answer has two parts. First, I show you what happens (there is bug that should be corrected!). I am not able to fully explain why this happens (maybe a quite recent change in Maxima, but maybe not...). Then I give you a workaround (that is better to use I think even when the bug will be removed).

Let me denote by $p$ your degree-$12$ polynomial, and by $q$ the degree-$10$ polynomial. The command you typed makes a call to the software Maxima. It happens that Maxima is able to find the approximate roots of $p$, and returns something like [[x == -1.99194847020934], [x == -1.927925665494726], ..., [x == 1.967859308671922]] (though in its own language), and Sage correctly transforms it to its representation. Everything's fine! For $q$, Maxima is unable to solve it (I do not know why) and returns something like [0 == 2*x^5 - 10*x^3 + 10*x + sqrt(5) + 1, 0 == 2*x^5 - 10*x^3 + 10*x - sqrt(5) + 1]. But the problem is as follows: Sage expects that Maxima raises an error when it is unable to find explicit solutions. This is apparently not the case! (Here, this may come from a change in Maxima, I have to investigate further.) So since there is no error from Maxima, Sage thinks that Maxima returned explicit solutions and tries to convert. This is where the IndexError appears since the answer from Maxima has not the required form.

For your problem, there are alternative methods to use, that are better to my mind – that is faster, safer, with better error guarantees. You first declare a polynomial ring in x over the integers and the polynomial you want to work with:

sage: R.<x> = ZZ[]
sage: q = x^10 - 10*x^8 + 35*x^6 + x^5 - 50*x^4 - 5*x^3 + 25*x^2 + 5*x - 1


Then you can ask for the roots of your polynomials in RR which is the floating-point representation of the real numbers, or in AA which is the field of (exactly-represented) algebraic real numbers:

sage: q.roots(RR)
[(-1.98422940262896, 1),
(-1.85955297177650, 1),
(-1.27484797949738, 1),
(-0.851558583130145, 1),
(-0.374762629171449, 1),
(0.125581039058627, 1),
(1.07165358995799, 1),
(1.45793725484282, 1),
(1.75261336008773, 1),
(1.93716632225726, 1)]
sage: q.roots(AA, multiplicities=False)
[-1.984229402628956?,
-1.859552971776503?,
-1.274847979497380?,
-0.8515585831301453?,
-0.3747626291714493?,
0.1255810390586268?,
1.071653589957994?,
1.457937254842823?,
1.752613360087728?,
1.937166322257263?]


Note that though you only see a finite number of decimals in the case of AA, roots are actually exactly represented as algebraic numbers, meaning that you can ask for as many decimals as you want and they will always be correct:

sage: r = q.roots(AA, multiplicities=False)[0]
sage: RR(r) r.n() # 53 bits of precision
-1.98422940262896
sage: RealField(500)(r) r.n(500) # 500 bits of precision
-1.98422940262895566209958608557155704290607341793759147174204245282176622450543068323073533550690797129244633009657456338304984019241338312932708655898


My answer has two parts. First, I show you what happens (there is bug that should be corrected!). corrected! → this is now #20436). I am not able to fully explain why this happens (maybe a quite recent change in Maxima, but maybe not...). Then I give you a workaround (that is better to use I think even when the bug will be removed).

Let me denote by $p$ your degree-$12$ polynomial, and by $q$ the degree-$10$ polynomial. The command you typed makes a call to the software Maxima. It happens that Maxima is able to find the approximate roots of $p$, and returns something like [[x == -1.99194847020934], [x == -1.927925665494726], ..., [x == 1.967859308671922]] (though in its own language), and Sage correctly transforms it to its representation. Everything's fine! For $q$, Maxima is unable to solve it (I do not know why) and returns something like [0 == 2*x^5 - 10*x^3 + 10*x + sqrt(5) + 1, 0 == 2*x^5 - 10*x^3 + 10*x - sqrt(5) + 1]. But the problem is as follows: Sage expects that Maxima raises an error when it is unable to find explicit solutions. This is apparently not the case! (Here, this may come from a change in Maxima, I have to investigate further.) So since there is no error from Maxima, Sage thinks that Maxima returned explicit solutions and tries to convert. This is where the IndexError appears since the answer from Maxima has not the required form.

For your problem, there are alternative methods to use, that are better to my mind – that is faster, safer, with better error guarantees. You first declare a polynomial ring in x over the integers and the polynomial you want to work with:

sage: R.<x> = ZZ[]
sage: q = x^10 - 10*x^8 + 35*x^6 + x^5 - 50*x^4 - 5*x^3 + 25*x^2 + 5*x - 1


Then you can ask for the roots of your polynomials in RR which is the floating-point representation of the real numbers, or in AA which is the field of (exactly-represented) algebraic real numbers:

sage: q.roots(RR)
[(-1.98422940262896, 1),
(-1.85955297177650, 1),
(-1.27484797949738, 1),
(-0.851558583130145, 1),
(-0.374762629171449, 1),
(0.125581039058627, 1),
(1.07165358995799, 1),
(1.45793725484282, 1),
(1.75261336008773, 1),
(1.93716632225726, 1)]
sage: q.roots(AA, multiplicities=False)
[-1.984229402628956?,
-1.859552971776503?,
-1.274847979497380?,
-0.8515585831301453?,
-0.3747626291714493?,
0.1255810390586268?,
1.071653589957994?,
1.457937254842823?,
1.752613360087728?,
1.937166322257263?]


Note that though you only see a finite number of decimals in the case of AA, roots are actually exactly represented as algebraic numbers, meaning that you can ask for as many decimals as you want and they will always be correct:

sage: r = q.roots(AA, multiplicities=False)[0]
sage: r.n() # 53 bits of precision
-1.98422940262896
sage: r.n(500) # 500 bits of precision
-1.98422940262895566209958608557155704290607341793759147174204245282176622450543068323073533550690797129244633009657456338304984019241338312932708655898