In my student's original code, he didn't even _need_ access to the variable name that he gave when running q_eigenform; he just needed to compute the valuation of a specific element of the number field he was creating, at a prime ideal he was about to create by factoring a rational prime number. If creating variable names for number fields is so fraught with difficulty, is there any way of avoiding this completely? My memory was that in magma you could just build a number field from a polynomial and if you didn't give it a variable name which was to correspond to a root of the polynomial then magma would just name it something like $.1 and not worry about it any more. This is the situation I think we're in here -- but in sage f.q_eigenform(10,'') and f.q_eigenform(10) both throw ValueErrors. I am now terrified to write any code containing loops and q_eigenform! Even running the same code twice in a session sounds to me to be dangerous.
Kevin On 5 May 2016 at 10:00, Peter Bruin <[email protected]> wrote: > Hi all, > > David is certainly correct that there is a problem with number fields > and coercion. The following example runs into the same (or at least a > similar) bug: > > k.<zeta10> = CyclotomicField(10) > R.<x> = PolynomialRing(k) > f0 = x^2 + (zeta10 + 1)*x + zeta10^2 - 2*zeta10 + 1 > K.<alpha> = k.extension(f0) > f1 = f0.base_extend(K) > print f0 > assert(f0(alpha) == 0) > print f1 > assert(f1(alpha) == 0) > # del K, alpha, f0, f1; import gc; gc.collect() > g0 = x^2 + (zeta10^3 + 1)*x - 2*zeta10^3 - zeta10 + 1 > K.<alpha> = k.extension(g0) > g1 = g0.base_extend(K) > print g0 > assert(g0(alpha) == 0) > print g1 > assert(g1(alpha) == 0) > > In at least Sage 7.2.beta5 and 7.2.beta6, the last assertion fails. > Uncommenting the line starting with "del ..." makes the problem go away > (in a fresh Sage session). > > Peter > > > 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 > > -- > 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 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. -- 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.
