Wow, David, this is a great response! Indeed, it seems quite absurd to me that picking the same name for a generator can produce such strange results, but at least the fix isn't too hard. It seems to have fixed my problems for now :-).
Thanks! Misja On 4 May 2016 at 09:55, David Loeffler <[email protected]> wrote: > Hi Kevin and Misja, > > This has something to do with the fraught issue of *variable names*. > Kevin's code prints a mixture of True's and False's; but, on the other > hand, if you run the code > > sage: G=DirichletGroup(80); > sage: for chi in G: > > D=ModularSymbols(chi,2,-1).cuspidal_subspace().new_subspace().decomposition() > for f in D: > elt=f.q_eigenform(10,'alpha' + str(randint(1,1000)))[3]; > print(elt.is_integral()) > > then you get all True's (at least, with rather high probability!). (Or, > more civilised: replace str(randint(1, 1000)) with str(f.factor_number()), > which is just an arbitrary ordering on the decomposition factors of a given > Hecke module.) > > There's a natural response that this is absurd -- how can the name given > to a variable affect its behaviour, in any sane environment? if I remember > correctly, the reason for this is that Sage's coercion system has to have a > way of knowing when two "number field" Sage objects with the same defining > polynomial are supposed to represent the same field (so there is a > canonical map between them) and when they're supposed to represent > different, non-canonically-isomorphic fields. Sage's solution is to assume > that if two number field objects have the same defining polynomial *and the > same generator name*, then they're identical. This leads to weird behaviour > when you create a bunch of number fields one after the other and call the > generators "alpha" in each case. > > So now you know why the default behaviour of the "Newforms" constructor is > to append an integer to the variable names -- if you do > "Newforms(DirichletGroup(80), names='alpha')" you'll get coefficient fields > with generators alpha0, alpha1, etc (not all alpha). I'll leave it to > other, more expert users to comment on why the collision of names causes > the exact bug above, but hopefully this should give you the means to work > around it. > > David > > On 3 May 2016 at 17:07, Kevin Buzzard <[email protected]> wrote: > >> Here's a shorter version of the code which I think already exhibits a >> problem. I should say that I'm currently only just learning sage so I might >> be victim to a gotcha. But here we go: >> >> 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]; >> print(elt.is_integral()) >> >> If I cut and paste this into a sage session (either 6.4.1 or 7.0 on >> Ubuntu 14.04) I get mostly true's but a few false's. My understanding is >> that I'm computing cuspidal new eigenforms here and checking to see that >> the coefficient of q^3 is an algebraic integer in each case. It sometimes >> isn't. What are we doing wrong? >> >> Kevin >> >> >> >> >> On Thursday, 28 April 2016 15:12:15 UTC+1, John Cremona wrote: >>> >>> ---------- Forwarded message ---------- >>> From: Misja <[email protected]> >>> Date: 28 April 2016 at 15:09 >>> Subject: [sage-support] Mysterious behaviour of q_eigenform... Bug? >>> To: sage-support <[email protected]> >>> >>> >>> 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! >>> >>> -- >>> 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 [email protected]. >>> To post to this group, send email to [email protected]. >>> Visit this group at https://groups.google.com/group/sage-support. >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "sage-nt" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> >> Visit this group at https://groups.google.com/group/sage-nt. >> For more options, visit https://groups.google.com/d/optout. >> > > -- > You received this message because you are subscribed to a topic in the > Google Groups "sage-nt" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/sage-nt/NM7bbCgefdo/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/sage-nt. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "sage-nt" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send an email to [email protected]. Visit this group at https://groups.google.com/group/sage-nt. For more options, visit https://groups.google.com/d/optout.
