Re: Algebra and (relative) number field change in behaviour between 2.13.4 and 2.14

[James Rickards <James.Rickards@colorado.edu>]

Dear Bill,

Very interesting, thanks! I guess I'll go through and implement the inelegant but basis-safe tests.

James

---

From: Bill Allombert <Bill.Allombert@math.u-bordeaux.fr>
Sent: Friday, June 10, 2022 1:33 PM
To: pari-users@pari.math.u-bordeaux.fr <pari-users@pari.math.u-bordeaux.fr>
Subject: Re: Algebra and (relative) number field change in behaviour between 2.13.4 and 2.14

 

On Fri, Jun 10, 2022 at 07:10:25PM +0000, James Rickards wrote:
> I was switching between 2.13.4 and 2.14, and noticed that some examples in my testing file no longer worked. For reference, the broken cases came from when I initialized an algebra, and considered an Eichler order contained within. It is very important that we get the exact same algebra every time, so that the claimed Eichler order is indeed an order. I assumed that the following code was safe:
> setrand(1);
> F=nfinit(y^3-5*y+1);
> setrand(1);
> A=alginit(F, [52*y^2 - 316*y - 363, -y^2 + 3*y - 9]);
> However, I've run into two issues, stemming from the fact that this gives different results on 2.13.4 and 2.14.
>
>   1.  The maximal order in A computed is different. I was able to solve this by installing alg_changeorder, and storing the desired maximal order in the testing file.
>   2.  Despite this, something was still amiss! It turns out that the rnf stored in A (A[1]=algsplittingfield(A)) is slightly different.
>
> In particular, the maximal order computed in this rnf is different. This can be recreated with the code:
> setrand(1);
> F=nfinit(y^3-5*y+1);
> L=rnfinit(F, x^2-(52*y^2 - 316*y - 363));
> nfinit(L).zk
> The 5th entry of this basis differs between 2.13.4 and 2.14.
>
> To account for this, the one idea I have is to store all algebra basis
> elements in terms of their algebraic representation, and convert
> everything to the basis representation in the testing file. I think
> this should work, but it is very inelegant.

Alas this is probably the best.

> Would there be a better way to ensure I get the same results every
> time? I assumed that using setrand() would be safe across versions,
> but I guess it is not.

The issue is that the fpLLL algorithm used by PARI does not return
canonical bases, and minor changes to the fpLLL implementation leads to
different bases. The upside is that LLL in PARI 2.14 is much faster than
in PARI 2.13.4.

Cheers,
Bill.