I am using development commit 22923-b7a1fcd which is a few commits past 2.11.0.
I am computing some modular forms, and their q-expansion coefficients a_n. In cases where these are not rational, most of them are returned as t_POLMOD e.g. Mod(t^3 - t^2 + t - 1, t^4 + t^3 + t^2 + t + 1), with the same modulus throughout, and that is fine. However, sometimes *but not always* a_0=0 ad a_1=1 with type t_INT, sometimes they look the same but have type t_POLMOD, and sometimes they look like genuine polmods, e.g. a_1=Mod(1, t^4 + t^3 + t^2 + t + 1). This inconsistency is causing bugs in my programs. (example below).
Right now I am just computing traces of these a_n, which is much harder than it should be. For a genuine t_POLMOD value a_n, trace(a_n) gives the right answer. If they happen to be t_INT then one hits the incredible pari/gp convention that trace(1)=2, and in general the trace of any t_INT doubles it. I for one think that is mad (if I want my 1 to be a complex number I will tell you!). If these were consistently polmods this would not arise.
I think this only affects a_0 and a_1, so I can write around it since my newforms are cuspidal (a_0=0) and of course normalized (a_1=1) so I can compyte trace(a_1) = degree of the polmod's modulus, but I don't think that I should have to do that.
Example:
N=11;
k=3;
G=znstar(N,1);
chi=[G,[1]];
Snew=mfinit([N,k,chi],0);
newforms=mfeigenbasis(Snew);
coeffs=mfcoefs(Snew,5);
ans1 = vector(#newforms, i, coeffs * mftobasis(Snew,newforms[i]));
\\ now ans 1 is: [[0, 1, Mod(t^3 - t^2 + t - 1, t^4 + t^3 + t^2 + t + 1), ...
N=4;
k=11;
G=znstar(N,1);
chi=[G,[1]];
Snew=mfinit([N,k,chi],0);
newforms=mfeigenbasis(Snew);
coeffs=mfcoefs(Snew,5);
ans2 = vector(#newforms, i, coeffs * mftobasis(Snew,newforms[i]));
\\ now ans2 is: [[Mod(0, y^4 + 12*y^3 + 64*y^2 + 12288*y + 1048576), Mod(1, y^4 + 12*y^3 + 64*y^2 + 12288*y + 1048576), Mod(y, y^4 + 12*y^3 + 64*y^2 + 12288*y + 1048576),...
John