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 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.
