> Yeah. Precision there bears more thinking on. I was actually even > considering > having precisions and valuations normalized so that valuation(p) = 1, > and then only > integral precisions would be allowed. I'm not sure whether I like > this idea though...
I'm sure I do not like that idea. That's not the language in which "algorithms over arbitrary complete discrete valuation rings" are normally formulated. Ultimately, I would like that if someone defines Zp=pAdicRing(5,prec=20) R.<X>=Zp[] A.<pi>=EisensteinExtension(X^3+5*X+5) then elements in A should behave as a0+a1*pi+a2*pi^2+...+ar*pi^r+O(pi^(r+1)) where the ai are representatives of the residue field (here GF(5)) It may well be that in order to have efficient arithmetic, you end up implementing it as a polynomial quotient ring, but then the behaviour should be modified to be consistent with the above model. In particular, if you represent your elements as (b0+O(p^e0))+(b1+O(p^e1)*pi+...+(b(n-1)+O(p^e(n-1)))*pi^(n-1) then some thought will be required on what to do with "excess precision" in one of the coefficients. It could well be that other "rawer" models also have their application, but I found that the p-adic extensions as, for instance, implemented in magma, allowed me to write programs that test for local solvability etc. that would work in arbitrary extensions. [whatever model you come up with, it should behave well wrt towers: Ultimately, we'll probably end up making unramified extensions of eisenstein extensions of unramified extenstions etc... In magma, this works seamlessly] --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~----------~----~----~----~------~----~------~--~---
