Revision history [back]

You are right, it is a bug.

If we explore the source code of the .minpoly() method (by typing A.minpoly??), we can see that the problem is in the computation of f.radical().

sage: f = A.charpoly()
sage: f
x^6 - 12.0000000000000*x^5 + 59.0000000000000*x^4 - 168.000000000000*x^3 + 351.000000000000*x^2 - 540.000000000000*x + 405.000000000000
x^6 - 12.0000000000000*x^5 + 59.0000000000000*x^4 - 168.000000000000*x^3 + 351.000000000000*x^2 - 540.000000000000*x + 405.000000000000


Indeed:

sage: f.factor()
(x - 3.00000000000000)^4 * (x^2 + 5.00000000000000)
(x - 3.00000000000000) * (x^2 + 5.00000000000000)


You are right, it is a bug.

If we explore the source code of the .minpoly() method (by typing A.minpoly??), we can see that the problem is in the computation of f.radical().

sage: f = A.charpoly()
sage: f
x^6 - 12.0000000000000*x^5 + 59.0000000000000*x^4 - 168.000000000000*x^3 + 351.000000000000*x^2 - 540.000000000000*x + 405.000000000000
x^6 - 12.0000000000000*x^5 + 59.0000000000000*x^4 - 168.000000000000*x^3 + 351.000000000000*x^2 - 540.000000000000*x + 405.000000000000


Indeed:

sage: f.factor()
(x - 3.00000000000000)^4 * (x^2 + 5.00000000000000)
(x - 3.00000000000000) * (x^2 + 5.00000000000000)


Inspecting further, we can see that the bug in the computation of f.radical() is in the computation of the gcd between f and its derivative:

sage: f.gcd(f.derivative())
1.00000000000000
sage: f.derivative()
6.00000000000000*x^5 - 60.0000000000000*x^4 + 236.000000000000*x^3 - 504.000000000000*x^2 + 702.000000000000*x - 540.000000000000
sage: f.derivative().factor()
(6.00000000000000) * (x - 3.00000000000000)^3 * (x^2 - x + 3.33333333333333)


You are right, it is a bug.

If we explore the source code of the .minpoly() method (by typing A.minpoly??), we can see that the problem is in the computation of f.radical().

sage: f = A.charpoly()
sage: f
x^6 - 12.0000000000000*x^5 + 59.0000000000000*x^4 - 168.000000000000*x^3 + 351.000000000000*x^2 - 540.000000000000*x + 405.000000000000
x^6 - 12.0000000000000*x^5 + 59.0000000000000*x^4 - 168.000000000000*x^3 + 351.000000000000*x^2 - 540.000000000000*x + 405.000000000000


Indeed:

sage: f.factor()
(x - 3.00000000000000)^4 * (x^2 + 5.00000000000000)
(x - 3.00000000000000) * (x^2 + 5.00000000000000)


Inspecting further, we can see that the bug in the computation of f.radical() is in the computation of the gcd between f and its derivative:

sage: f.gcd(f.derivative())
1.00000000000000
sage: f.derivative()
6.00000000000000*x^5 - 60.0000000000000*x^4 + 236.000000000000*x^3 - 504.000000000000*x^2 + 702.000000000000*x - 540.000000000000
sage: f.derivative().factor()
(6.00000000000000) * (x - 3.00000000000000)^3 * (x^2 - x + 3.33333333333333)


Which is told in the documentation of the .gcd() method : "Unless the division is exact (i.e. no rounding occurs) the returned gcd is almost certain to be 1".

There are various possibities to fix this:

• In the .minpoly() method, we can start with mp = f.parent().one_element() instead of mp = f.radical(), remove the condition if e > 1: and replace mp *= h**(n-1) by mp *= h**(n-1).

• In the .radical() method, use factorization instead of gcd.

• In the .gdc() method, use factorization instead of Euclid algorithm (if one can guarantee that this will lead to less errors).

You are right, it is a bug.bug. Thanks for reporting.

If we explore the source code of the .minpoly() method (by typing A.minpoly??), we can see that the problem is in the computation of f.radical().

sage: f = A.charpoly()
sage: f
x^6 - 12.0000000000000*x^5 + 59.0000000000000*x^4 - 168.000000000000*x^3 + 351.000000000000*x^2 - 540.000000000000*x + 405.000000000000
x^6 - 12.0000000000000*x^5 + 59.0000000000000*x^4 - 168.000000000000*x^3 + 351.000000000000*x^2 - 540.000000000000*x + 405.000000000000


Indeed:

sage: f.factor()
(x - 3.00000000000000)^4 * (x^2 + 5.00000000000000)
(x - 3.00000000000000) * (x^2 + 5.00000000000000)


Inspecting further, we can see that the bug in the computation of f.radical() is in the computation of the gcd between f and its derivative:

sage: f.gcd(f.derivative())
1.00000000000000
sage: f.derivative()
6.00000000000000*x^5 - 60.0000000000000*x^4 + 236.000000000000*x^3 - 504.000000000000*x^2 + 702.000000000000*x - 540.000000000000
sage: f.derivative().factor()
(6.00000000000000) * (x - 3.00000000000000)^3 * (x^2 - x + 3.33333333333333)


Which is told in the documentation of the .gcd() method : "Unless the division is exact (i.e. no rounding occurs) the returned gcd is almost certain to be 1".

There are various possibities to fix this:

• In the .minpoly() method, we can start with mp = f.parent().one_element() instead of mp = f.radical(), remove the condition if e > 1: and replace mp *= h**(n-1) by mp *= h**(n-1).

• In the .radical() method, use factorization instead of gcd.

• In the .gdc() method, use factorization instead of Euclid algorithm (if one can guarantee that this will lead to less errors).

You are right, it is a bug. Thanks for reporting.

If we explore the source code of the .minpoly() method (by typing A.minpoly??), we can see that the problem is in the computation of f.radical().

sage: f = A.charpoly()
sage: f
x^6 - 12.0000000000000*x^5 + 59.0000000000000*x^4 - 168.000000000000*x^3 + 351.000000000000*x^2 - 540.000000000000*x + 405.000000000000
x^6 - 12.0000000000000*x^5 + 59.0000000000000*x^4 - 168.000000000000*x^3 + 351.000000000000*x^2 - 540.000000000000*x + 405.000000000000


Indeed:

sage: f.factor()
(x - 3.00000000000000)^4 * (x^2 + 5.00000000000000)
(x - 3.00000000000000) * (x^2 + 5.00000000000000)


Inspecting further, we can see that the bug in the computation of f.radical() is in the computation of the gcd between f and its derivative:

sage: f.gcd(f.derivative())
1.00000000000000
sage: f.derivative()
6.00000000000000*x^5 - 60.0000000000000*x^4 + 236.000000000000*x^3 - 504.000000000000*x^2 + 702.000000000000*x - 540.000000000000
sage: f.derivative().factor()
(6.00000000000000) * (x - 3.00000000000000)^3 * (x^2 - x + 3.33333333333333)


Which is told in the documentation of the .gcd() method : "Unless the division is exact (i.e. no rounding occurs) the returned gcd is almost certain to be 1".

There are various possibities to fix this:

• In the .minpoly() method, we can start with mp = f.parent().one_element() instead of mp = f.radical(), remove the condition if e > 1: and replace mp *= h**(n-1) by mp *= h**(n-1).

• In the .radical() method, use factorization instead of gcd.

• In the .gdc() method, use factorization instead of Euclid algorithm gcd (if one can guarantee that this will lead to less errors).

• In the .gdc() method, use factorization instead of Euclid algorithm (if one can guarantee that this will lead to less errors).

You are right, it is a bug. Thanks for reporting.

If we explore the source code of the .minpoly() method (by typing A.minpoly??), we can see that the problem is in the computation of f.radical().

sage: f = A.charpoly()
sage: f
x^6 - 12.0000000000000*x^5 + 59.0000000000000*x^4 - 168.000000000000*x^3 + 351.000000000000*x^2 - 540.000000000000*x + 405.000000000000
x^6 - 12.0000000000000*x^5 + 59.0000000000000*x^4 - 168.000000000000*x^3 + 351.000000000000*x^2 - 540.000000000000*x + 405.000000000000


Indeed:

sage: f.factor()
(x - 3.00000000000000)^4 * (x^2 + 5.00000000000000)
(x - 3.00000000000000) * (x^2 + 5.00000000000000)


Inspecting further, we can see that the bug in the computation of f.radical() is in the computation of the gcd between f and its derivative:

sage: f.gcd(f.derivative())
1.00000000000000
sage: f.derivative()
6.00000000000000*x^5 - 60.0000000000000*x^4 + 236.000000000000*x^3 - 504.000000000000*x^2 + 702.000000000000*x - 540.000000000000
sage: f.derivative().factor()
(6.00000000000000) * (x - 3.00000000000000)^3 * (x^2 - x + 3.33333333333333)


Which is told in the documentation of the .gcd() method : "Unless the division is exact (i.e. no rounding occurs) the returned gcd is almost certain to be 1".

There are various possibities to fix this:

• In the .minpoly() method, we can start with mp = f.parent().one_element() instead of mp = f.radical(), remove the condition if e > 1: and replace mp *= h**(n-1) by mp *= h**(n-1) and add mp *= h if e == 1.

• In the .radical() method, use factorization instead of gcd (if one can guarantee that this will lead to less errors).

• In the .gdc() method, use factorization instead of Euclid algorithm (if one can guarantee that this will lead to less errors).

You are right, it is a bug. Thanks for reporting.

If we explore the source code of the .minpoly() method (by typing A.minpoly??), we can see that the problem is in the computation of f.radical().

sage: f = A.charpoly()
sage: f
x^6 - 12.0000000000000*x^5 + 59.0000000000000*x^4 - 168.000000000000*x^3 + 351.000000000000*x^2 - 540.000000000000*x + 405.000000000000
x^6 - 12.0000000000000*x^5 + 59.0000000000000*x^4 - 168.000000000000*x^3 + 351.000000000000*x^2 - 540.000000000000*x + 405.000000000000


Indeed:

sage: f.factor()
(x - 3.00000000000000)^4 * (x^2 + 5.00000000000000)
(x - 3.00000000000000) * (x^2 + 5.00000000000000)


Inspecting further, we can see that the bug in the computation of f.radical() is in the computation of the gcd between f and its derivative:

sage: f.gcd(f.derivative())
1.00000000000000
sage: f.derivative()
6.00000000000000*x^5 - 60.0000000000000*x^4 + 236.000000000000*x^3 - 504.000000000000*x^2 + 702.000000000000*x - 540.000000000000
sage: f.derivative().factor()
(6.00000000000000) * (x - 3.00000000000000)^3 * (x^2 - x + 3.33333333333333)


Which is told in the documentation of the .gcd() method : "Unless the division is exact (i.e. no rounding occurs) the returned gcd is almost certain to be 1".

There are various possibities to fix this:

• In the .minpoly() method, we can start with mp = f.parent().one_element() instead of mp = f.radical(), replace mp *= h**(n-1) by mp *= h**(n-1) and add mp *= h if e == 1.

• In the .radical() method, use factorization instead of gcd (if one can guarantee that this will lead to less errors).

• In the .gdc() method, use factorization instead of Euclid algorithm (if one can guarantee that this will lead to less errors).errors). The problem is that factorization is much slower.

You are right, it is a bug. Thanks for reporting.

If we explore the source code of the .minpoly() method (by typing A.minpoly??), we can see that the problem is twofold:

in the test of squarefreeness of f:

sage: f = A.charpoly()
sage: f
x^6 - 12.0000000000000*x^5 + 59.0000000000000*x^4 - 168.000000000000*x^3 + 351.000000000000*x^2 - 540.000000000000*x + 405.000000000000
sage: f.is_squarefree()
True


and (if we skip this shortcut) in the computation of f.radical().

sage: f = A.charpoly()
sage: f
x^6 - 12.0000000000000*x^5 + 59.0000000000000*x^4 - 168.000000000000*x^3 + 351.000000000000*x^2 - 540.000000000000*x + 405.000000000000
x^6 - 12.0000000000000*x^5 + 59.0000000000000*x^4 - 168.000000000000*x^3 + 351.000000000000*x^2 - 540.000000000000*x + 405.000000000000


Indeed:

sage: f.factor()
(x - 3.00000000000000)^4 * (x^2 + 5.00000000000000)
(x - 3.00000000000000) * (x^2 + 5.00000000000000)


Inspecting further, we can see that the bug in the computation of f.radical() is in the computation of the gcd between f and its derivative:

sage: f.gcd(f.derivative())
1.00000000000000
sage: f.derivative()
6.00000000000000*x^5 - 60.0000000000000*x^4 + 236.000000000000*x^3 - 504.000000000000*x^2 + 702.000000000000*x - 540.000000000000
sage: f.derivative().factor()
(6.00000000000000) * (x - 3.00000000000000)^3 * (x^2 - x + 3.33333333333333)


Which is told in the documentation of the .gcd() method : "Unless the division is exact (i.e. no rounding occurs) the returned gcd is almost certain to be 1".

There are various possibities to fix this:

• In the .minpoly() method, we can start with mp = f.parent().one_element() instead of mp = f.radical(), replace mp *= h**(n-1) by mp *= h**(n-1) and add mp *= h if e == 1.

• In the .radical() method, use factorization instead of gcd (if one can guarantee that this will lead to less errors).

• In the .gdc() method, use factorization instead of Euclid algorithm (if one can guarantee that this will lead to less errors). The problem is that factorization is much slower.