Mysterious behaviour of q_eigenform... Bug?

[Misja]

When understand the specific reason why my code is not working properly, I managed to pin it down to the following mysterious behaviour of q_eigenform.

First run the following code in sage.

G=DirichletGroup(80);

chi=G[22];

D=ModularSymbols(chi,2,-1).cuspidal_subspace().new_subspace().decomposition();

for f in D:

    elt=f.q_eigenform(10,'alpha')[3];

    N=elt.parent().absolute_field('a');

    fact=N.factor(2);

    for P,e in fact:

        res_field=N.residue_field(P);
        print res_field(elt);

It will print 

0

0

0

0

which, I think, is the 'right' answer.

Now close your sage session entirely. Open a new session and then run the following *silly* code:

G=DirichletGroup(80);

for chi in G:

    D=ModularSymbols(chi,2,-1).cuspidal_subspace().new_subspace().decomposition();

    for f in D:

        elt=f.q_eigenform(10,'alpha')[3];

        if not elt.parent()==QQ:

            K=elt.parent().absolute_field('b');

            if chi==G[22]:

                fact=K.factor(2);

                for P,e in fact:

                    res_field=K.residue_field(P);

                    print res_field(elt); 

It will print:

0

0

1

0

As far as I understand the theory, this cannot happen. If you let sage print the alpha^3 coefficient of you see that in both cases it picks a different q_eigenform in f, the Galois conjugacy class of newforms. Although this can be a bit annoying, in theory it is fine. But I am pretty sure that when your reduce this coefficient modulo some prime P, any two elements of the same Galois conjugacy class can differ at most by some automorphism of the residue field (and obviously 1 and 0 do not satisfy this criterion).


To make matters worse: if you run a single sage session and you run the 'good' code first and the 'bad' code second, then suddenly the 'bad' code is fixed and printing only 0s. If you run the 'bad' code first and the 'good' code second, then they are both 'bad' and the 'good' code suddenly prints 0,0,1,0 as well. 

By trying I found out that this is because somehow  q_eigenform picks the same q_eigenform as whichever code that ran first and somehow these choices are not compatible! I don't know the inner workings of q_eigenform, but this behaviour seems strange to me.

Can anyone explain what is going on here? Is it a bug?

Thanks!

[John Cremona]

I have forwarded your question to sage-nt@googlegroups since there are
people who read that who may be able to answer yet do not read
sage-support.

Feel free to apply to join sage-nt.

John Cremona

> --
> You received this message because you are subscribed to the Google Groups
> "sage-support" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-support...@googlegroups.com.
> To post to this group, send email to sage-s...@googlegroups.com.
> Visit this group at https://groups.google.com/group/sage-support.
> For more options, visit https://groups.google.com/d/optout.

[Misja]

Thank you very much! I didn't know sage-nt existed :-)

Misja

[David Loeffler]

What happens if you run the bad code, then run "ModularSymbols_clear_cache()", then the good code? Do you get the same discrepancy?

David

[Misja]

Hi David,

Thanks for your reply! It's a good test to do (that I hadn't thought of before), but unfortunately even with 'ModularSymbols_clear_cache()' in between the two runs, the 'good' code is still printing the wrong answer in a second run. Could it be another (i.e. non-modular symbols) caching problem?

Misja

[Kevin Buzzard]

Hi Misja. Your silly code works fine for me on ubuntu 14.04 with sage version 6.4.1 (I get zeroes), but I can reproduce your random '1' with sage 7.0.0. I can confirm that after the bad code has run once on 7.0.0, David's suggestion of clearing the modular symbols cache does not fix the problem -- I still get a 1.

Kevin

$ sage

┌────────────────────────────────────────────────────────────────────┐

│ Sage Version 6.4.1, Release Date: 2014-11-23                       │

│ Type "notebook()" for the browser-based notebook interface.        │

│ Type "help()" for help.                                            │

└────────────────────────────────────────────────────────────────────┘

sage: %cpaste

Pasting code; enter '--' alone on the line to stop or use Ctrl-D.

:G=DirichletGroup(80);

:for chi in G:

:    D=ModularSymbols(chi,2,-1).cuspidal_subspace().new_subspace().decomposition();

:    for f in D:

:        elt=f.q_eigenform(10,'alpha')[3];

:        if not elt.parent()==QQ:

:            K=elt.parent().absolute_field('b');

:            if chi==G[22]:

:                fact=K.factor(2);

:                for P,e in fact:

:                    res_field=K.residue_field(P);

:                    print res_field(elt); 

:<EOF>

0

0

0

0

sage: 

[Misja Steinmetz]

Interesting... Just to confirm: in the above I have been using SageMath Version 7.1 on Ubuntu 14.04 (sorry, I should have probably stated this way back when I posted the question). So it seems like it is a Sage 7.0+ problem!

--

You received this message because you are subscribed to a topic in the Google Groups "sage-support" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sage-support/OMjVE6YasdU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sage-support...@googlegroups.com.

[Kevin Buzzard]

 If you let sage print the alpha^3 coefficient of you see that in both cases it picks a different q_eigenform in f, the Galois conjugacy class of newforms.

Are you sure this is what is happening?

Version 7.0.0. When bad code isn't run, good code gives this:

sage: f.q_eigenform(10,'alpha')[3]

(-1/8*zeta4 - 1/4)*alpha^7 + (3/8*zeta4 + 1/8)*alpha^5 + (-1/4*zeta4 + 1)*alpha^3 + (-zeta4 - 1)*alpha

When bad code is run first, good code gives this:

sage: f.q_eigenform(10,'alpha')[3]

(2940134632232014408766657/19352042383840927420034024*zeta4 - 2565054267989270372493119/19352042383840927420034024)*alpha^7 + (-1869921197843988328685619/9676021191920463710017012*zeta4 - 1590788291043697551073545/4838010595960231855008506)*alpha^6 + (-487218429010828867191579/744309322455420285385924*zeta4 - 55395905851779626534807/372154661227710142692962)*alpha^5 + (-505556560719679641283131/744309322455420285385924*zeta4 + 395740922589971800357659/744309322455420285385924)*alpha^4 + (3091086773658381828546971/9676021191920463710017012*zeta4 + 22169159574776632616577397/9676021191920463710017012)*alpha^3 + (6474331895422395046208340/2419005297980115927504253*zeta4 - 2149434331277811094538751/4838010595960231855008506)*alpha^2 + (6666435583064028847954867/4838010595960231855008506*zeta4 - 12722634445968563495188259/4838010595960231855008506)*alpha - 940957015960155394979262/2419005297980115927504253*zeta4 - 3747940737545550772744377/2419005297980115927504253

I am not saying that these are definitely not Galois conjugate. But I am saying that I kind of suspect that these are not Galois conjugate. No! Wait! I am saying they're not Galois conjugate, because

elt=f.q_eigenform(10,'alpha')[3]

elt.minpoly()

gives 

x^8 + 16*zeta4*x^6 - 72*x^4 - 64*zeta4*x^2 + 4

if the bad code hasn't run yet, and

x^8 + (7998749126707393770675990/2419005297980115927504253*zeta4 - 47381022823029338213469198/2419005297980115927504253)*x^7 + (88328222560611710210573725/2419005297980115927504253*zeta4 + 402745578098164737879842397/2419005297980115927504253)*x^6 + (-1851973029418246178060665656/2419005297980115927504253*zeta4 - 972520883967381161087609244/2419005297980115927504253)*x^5 + (7012307362677246370736050995/2419005297980115927504253*zeta4 - 4497820941388198664887224012/2419005297980115927504253)*x^4 + (20664072505712818488383157852/2419005297980115927504253*zeta4 + 22847825216496581679001616316/2419005297980115927504253)*x^3 + (-2819149604897477732352436978/186077330613855071346481*zeta4 + 5847356735083004488400198448/186077330613855071346481)*x^2 + (-123986553349389596472324440088/2419005297980115927504253*zeta4 - 22346113370356065142956464904/2419005297980115927504253)*x - 769782031701554576146090878/2419005297980115927504253*zeta4 - 72076427755982334621542375888/2419005297980115927504253

if the bad code has run. We can even coerce elt into elt.parent().absolute_field('b') and then compute the min poly; if the bad code hasn't run the output is sane and if the bad code has run the output is not in Z[x]; thus it seems to me that if I've understood things correctly sage is saying that the coefficient of q^3 of this eigenform is not an algebraic integer, once the bad code has run. More precisely the LCM of the denominators occurring in the coefficients of the min poly once the bad code has run is

13 * 241 * 3541 * 2581177 * 84475877413

So here's a shorter working example of a problem.

First fire up sage 7.0.0 and then cut and paste the below bad code.

G=DirichletGroup(80);

for chi in G:

    D=ModularSymbols(chi,2,-1).cuspidal_subspace().new_subspace().decomposition();

    for f in D:

        elt=f.q_eigenform(10,'alpha')[3];

        if not elt.parent()==QQ:

            K=elt.parent().absolute_field('b');

            if chi==G[22]:

                fact=K.factor(2);

                for P,e in fact:

                    res_field=K.residue_field(P);

                    print res_field(elt); 

And then ignore all that (it has somehow corrupted something??) and do this:

G=DirichletGroup(80);

chi=G[22];

D=ModularSymbols(chi,2,-1).cuspidal_subspace().new_subspace().decomposition();

f=D[2]

elt=f.q_eigenform(10,'alpha')[3];

elt.is_integral()

and observe that we get "false". In fact none of the q-expansion coefficients are algebraic integers from q^2 to q^10.

Kevin

[Kevin Buzzard]

OK how about this for a minimal example of unexpected (to me) behaviour. I get problems with sage 6.4.1 and 7.0.0 with the below code.

G=DirichletGroup(80);

for chi in G: 

    D=ModularSymbols(chi,2,-1).cuspidal_subspace().new_subspace().decomposition(); 

    for f in D: 

        e=f.q_eigenform(10,'alpha')[3]; 

        print(e.is_integral())

I believe that this code just computes a bunch of random spaces of cuspidal new modular symbols and then for each conj class of eigenforms it finds, it checks to see if the coefficient of q^3 is an algebraic integer.

In sage 7.0 on Ubuntu 14.04 I get

True

True

True

False

True

True

True

True

True

True

True

True

True

True

True

True

False

True

True

True

False

True

False

Have I misunderstood something or is this a bug?

Kevin

On Thursday, 28 April 2016 15:09:59 UTC+1, Misja wrote:

[Misja]

Note: this issue was resolved by David Loeffler in the sage-nt group. See https://groups.google.com/forum/#!topic/sage-nt/NM7bbCgefdo