sage.libs.pari.gen.PariError: ZZ_123…1[y]/(y^2 + …) is not a field in FpX_ffintersect

[martin....@gmx.net]

I'm trying to find a formula concerned with some computation about the relative position of two ellipses. But some result along the way looks strange when evaluated with RDF numbers, and trying to plug in algebaric numbers instead, I encounter the following error message:

sage.libs.pari.gen.PariError: ZZ_123633238138850861[y]/(y^2 + 114948053005503479*y + 71680486823734693) is not a field in FpX_ffintersect

I have no clue what that error message means, and more importantly, how to avoid it. I've pasted my code from my norebook worksheet to https://gist.github.com/gagern/9320350. I tried to convert all the sage console output style back to sage input notation, with output as comments. Hope I didn't miss anything.

As you can see in that file, I've encountered quite a number of places where the current behavior of sage surprised or even annoyed me. The question I'm posting about now is question 6 from the comments in that file. But if anyone can contribute some insight to some of the other questions as well, that would be highly appreciated. If not, I might end up posting more mails about these as well. But right now, my most immediate problem is that about how to perform a proper algebraic computation on these expressions.

[Jeroen Demeyer]

On 2014-03-03 09:11, martin....@gmx.net wrote:
> sage.libs.pari.gen.PariError: ZZ_123633238138850861[y]/(y^2 + 114948053005503479*y + 71680486823734693) is not a field in FpX_ffintersect
>
> I have no clue what that error message means, and more importantly, how to avoid it.

The concrete problem (I guess) is that 123633238138850861 is not a prime
number. But now the question becomes: where does this number come from?

> I've pasted my code from my norebook worksheet to https://gist.github.com/gagern/9320350.

Can you please reduce the example code you posted? If you think this is
a bug in Sage, try to post the minimal amount of code that will
reproduce the bug.

[Jeroen Demeyer]

On 2014-03-03 09:11, martin....@gmx.net wrote:

> As you can see in that file, I've encountered quite a number of places where the current behavior of sage surprised or even annoyed me.

I think as a general rule, you should try to avoid symbolic computations
for any serious work. Try to convert your problem to use a polynomial
ring instead.

[martin....@gmx.net]

On Monday, March 3, 2014 11:30:50 AM UTC+1, Jeroen Demeyer wrote:

> I have no clue what that error message means, and more importantly, how to avoid it.
The concrete problem (I guess) is that 123633238138850861 is not a prime
number. But now the question becomes: where does this number come from?

I must confess that I also don't see why a computation involving algebraic numbers should involve operations over some finite field. But since I know only little about the implementation details of algebraic numbers, I'll accept any statement that there is a good reason for doing this. Nevertheless, knowing that reason might help figuring out what goes wrong here.
 

> I've pasted my code from my norebook worksheet to https://gist.github.com/gagern/9320350.
Can you please reduce the example code you posted? If you think this is
a bug in Sage, try to post the minimal amount of code that will
reproduce the bug.

I realize that reproducing this beast is pretty difficult: the first time I encounter one of these errors, it's this pari error about FpX_ffintersect, but if I execute exactly the same command a second time, I get the AttributeError for PolynomialTracker instead:

AttributeError: 'AlgebraicPolynomialTracker' object has no attribute '_gen'

This makes debugging the beast a lot harder, since I have to redo many computations for every step.

Nevertheless, here is a minimal example:
https://gist.githubusercontent.com/gagern/9320350/raw/d1896f7a5a05b24075098941c9c3ff156ca6c139/MinimalReprodcing6.sage

It is minimal in the following sense: For the whole expression, the minpoly call fails with the claimed error message. For each operand, however, it succeeds. If I recreate each operand from its minimal polynomial, the call succeeds as well. So it must be not only the value stored in the first operand, but also the way it is encoded, represented, references other things and so on. The whole thing is far from minimal in terms of code length, but as I said, I can't make the expression any easier and still reproduce the issue. In terms of number of commands, it should be fairly close to minimal, but the command defining the expression is huge.

On Monday, March 3, 2014 11:36:03 AM UTC+1, Jeroen Demeyer wrote:On 2014-03-03 09:11, martin....@gmx.net wrote:

I think as a general rule, you should try to avoid symbolic computations for any serious work. Try to convert your problem to use a polynomial ring instead.

I have to take square roots and even cubic roots along the way, which I can't do in a polynomial ring. At least not easily, not without defining a new field every time I need another square root. Or is there a simple way?

[martin....@gmx.net]

On Monday, March 3, 2014 5:31:18 PM UTC+1, martin....@gmx.net wrote:

Nevertheless, here is a minimal example:
https://gist.githubusercontent.com/gagern/9320350/raw/d1896f7a5a05b24075098941c9c3ff156ca6c139/MinimalReprodcing6.sage

It is minimal in the following sense: For the whole expression, the minpoly call fails with the claimed error message. For each operand, however, it succeeds. If I recreate each operand from its minimal polynomial, the call succeeds as well. So it must be not only the value stored in the first operand, but also the way it is encoded, represented, references other things and so on. The whole thing is far from minimal in terms of code length, but as I said, I can't make the expression any easier and still reproduce the issue. In terms of number of commands, it should be fairly close to minimal, but the command defining the expression is huge.

Using pdb, I've managed to look at the stack trace where the exception was raised, and obtain the polynomial which gets passed to pari. At https://gist.github.com/gagern/9320350#file-minimalreproducing8-sage I've used this to create yet another minimal reproducing example, MinimalReproducing8.sage, which is a lot shorter than my previous attempt. It seems that this particular polynomial cannot be handled, for some reason. I guess now is a good time for the bug report, even though the huge numbers involved still make this example longer than I'd whish for.

[Jeroen Demeyer]

On 2014-03-03 18:03, martin....@gmx.net wrote:
> I guess now is a good time for the bug report

Absolutely, go for it!

[martin....@gmx.net]

Reported as http://trac.sagemath.org/ticket/15886

Thanks for listening.