Witt Vectors

[tdupu]

An implementation of the ring of witt vectors and their elements for any commutative ring

[tdupu]

This is what it can do right now

sage: W = Big
Big_Witt_Ring    Big_Witt_Vector  
sage: W = Big_Witt_Ring(ZZ)
sage: x = [1 for i in range(10)]
sage: w = W(x)
sage: w+w
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)

/usr/local/sage-4.7/devel/sage-sandbox/<ipython console> in <module>()

TypeError: unsupported operand type(s) for +: 'Big_Witt_Vector' and 'Big_Witt_Vector'

[kcrisman]

Witt Vectors! Yes! That would be awesome. I will stay tuned.

By the way, you should feel free to "Replace existing attachment of the same name" so that you aren't attaching a million files. It could get sizeable after a while.

[tdupu]

roed314: the coercion system catches other problems and doesn't forward them all on your real problem is: 100 return x[0]

101 if n>0:

--> 102 divs = divisors(n)

103 dict = {} 104 wn = 0

NameError?: global name 'divisors' is not defined you need to import divisors from sage.rings.arith me: so you have to do like nn=Integer(n) nn.divisors()

roed314: that would work too then you have to import Integer from sage.rings.integer

[tdupu]

This was made during sage days 44. It runs. Unless I someone messed up when I uploaded this which is a real possibility.

[tdupu]

There is a problem in the division by p in characteristic p.

sage: a = pWittElement({0:GF(3)(1), 1:GF(3)(2), 2:GF(3)(2)}, Wp) 
sage: Wp=pWittVectors(GF(3),3)                                  
sage: a = pWittElement({0:GF(3)(1), 1:GF(3)(2), 2:GF(3)(2)}, Wp)
sage: a^2 + a
---------------------------------------------------------------------------
ZeroDivisionError                         Traceback (most recent call last)

/home/tdupu/sage-5.6/devel/sage-oms/<ipython console> in <module>()

/home/tdupu/sage-5.6/local/lib/python2.7/site-packages/sage/structure/element.so in sage.structure.element.RingElement.__pow__ (sage/structure/element.c:14627)()

/home/tdupu/sage-5.6/local/lib/python2.7/site-packages/sage/structure/element.so in sage.structure.element.generic_power_c (sage/structure/element.c:26200)()

/home/tdupu/sage-5.6/local/lib/python2.7/site-packages/sage/structure/element.so in sage.structure.element.RingElement.__mul__ (sage/structure/element.c:14096)()

/home/tdupu/sage-5.6/local/lib/python2.7/site-packages/sage/structure/element.so in sage.structure.element.RingElement._mul_ (sage/structure/element.c:14222)()

/home/tdupu/sage-5.6/local/lib/python2.7/site-packages/sage/rings/padics/witt.pyc in _mul_(self, other)
    219         a = self.dict
    220         b = other.dict      
--> 221         return C(wittprod(self.p,a,b), self.parent() )
    222         
    223     def frob(self):

/home/tdupu/sage-5.6/local/lib/python2.7/site-packages/sage/rings/padics/witt.pyc in wittprod(p, x, y)
    116     prod[0] = x[0]*y[0]
    117     for j in range(1,m):
--> 118         prod[j] = ( witt(p,j,x)*witt(p,j,y) - witt(p,j-1,frob(p,prod)) )/p**j 
    119     return prod
    120     

/home/tdupu/sage-5.6/local/lib/python2.7/site-packages/sage/structure/element.so in sage.structure.element.RingElement.__div__ (sage/structure/element.c:14855)()

/home/tdupu/sage-5.6/local/lib/python2.7/site-packages/sage/structure/coerce.so in sage.structure.coerce.CoercionModel_cache_maps.bin_op (sage/structure/coerce.c:6832)()

/home/tdupu/sage-5.6/local/lib/python2.7/site-packages/sage/structure/element.so in sage.structure.element.RingElement.__div__ (sage/structure/element.c:14834)()

/home/tdupu/sage-5.6/local/lib/python2.7/site-packages/sage/rings/finite_rings/integer_mod.so in sage.rings.finite_rings.integer_mod.IntegerMod_int._div_ (sage/rings/finite_rings/integer_mod.c:21514)()

ZeroDivisionError: Inverse does not exist.

[tdupu]

Hopefully I'm using mercurial right...

[roed]

It looks like the newest patch is formatted fine.

Does coercion from the integers into a ring of Witt Vectors work right? What is the image of p?

[tdupu]

Replying to roed:

It looks like the newest patch is formatted fine.

Does coercion from the integers into a ring of Witt Vectors work right? What is the image of p?

Coercion is not implemented. I'd also like to implement coercions for padics but I first need to deal with this division by p thing.

Also, I have some modifications that It won't let me refresh. I'm having trouble with these "phases". It's not letting me refresh the patch

(sage-sh) tdupu@tdupu-Gazelle-Professional:sage-oms$ hg qrefresh
abort: cannot refresh immutable revision
(see "hg help phases" for details)

I tried modifying my .hg/hgrc in my working branch of sage ~/sage-whatever like so

[phases]
publish = False

this isn't working.

[roed]

Replying to tdupu:

Replying to roed:

It looks like the newest patch is formatted fine.

Does coercion from the integers into a ring of Witt Vectors work right? What is the image of p?

Coercion is not implemented. I'd also like to implement coercions for padics but I first need to deal with this division by p thing.

Also, I have some modifications that It won't let me refresh. I'm having trouble with these "phases". It's not letting me refresh the patch

(sage-sh) tdupu@tdupu-Gazelle-Professional:sage-oms$ hg qrefresh
abort: cannot refresh immutable revision
(see "hg help phases" for details)

I tried modifying my .hg/hgrc in my working branch of sage ~/sage-whatever like so

[phases]
publish = False

this isn't working.

Weird. I have no idea what's going on there. Perhaps you should e-mail sage-devel?

[darij]

There are at least two issues with this implementation of Witt vectors:

1) The Frobenius map on the Witt vectors doesn't just take the p-th power of every coordinate. This is only true if p = 0 in the base ring.

2) The definition of Witt vector addition and multiplication through the ghost components don't work over a ring where p isn't invertible (or at least a non-zero divisor). This is why every time this definition is used to actually define the Witt vectors, it is accompanied by a functoriality condition.

I fear that fixing the issues requires rewriting the methods from scratch.

I am also wondering whether anything speaks against implementing Witt vectors for general nests as well (including the nest of all positive integers, leading to "big Witt vectors").

[kcrisman]

On an unrelated note, it would be helpful to know which (all? just the last two?) patches here are to be applied, and perhaps to make one big "master" patch as well, if relevant.

@darij: would it be possible to "fix" the issues you raise by appropriate documentation about allowable base rings (or even try/except or assert for inappropriate ones)? I do agree that whatever infrastructure is here should be robust enough to eventually support at least the big Witt vectors, if not even other sets. Maybe a placeholder class to inherit from...

Another thought - is there really any reason to have the functions wittsum etc. as separate functions?

Finally, there are various formatting issues, but that's not worth fixing until a more final patch, likely.

[darij]

Restricting the base ring? I don't think so. If we wanted to fix both issues at the same time this way, we'd have to restrict R to the zero ring, which is definitely not the intention ;) but even restricting to char-p or char-coprime-to-p only makes Witt vectors a lot less powerful.

[tdupu]

The reply button doesn't seem to be working.

Re Darij's Comments: 1) Do you mean p is the characteristic of the base ring? Yeah, this is an issue. I mentioned this before but still haven't fixed it. 2) The function also only works for p-typical witt vectors. There should be a slicker way of implementing this. The hard part is computing the witt polynomials.

Re: kcrisman's comments: -One could add change the flow of the code: Here is a quick-fix the characteristic of the base is zero then do this. If not they raise a NotImplementedError?.

-Also, the big witt vectors can not be implemented using what i did since I used that w_{n-1}(a^{p) + p}n a_n = w_n(a) in the recurrence.

-The witt sums and witt additions should be excluded because they may be used for Greenberg transforms (which will have applications to say lifting J-invariants). I have talked a little bit to Luis Finotti about this.

There are snippets of big witt vectors code in the original patches (not the pWittVectors patch) that can be used but the indexing is off in that code I think.

I will try and make a list of other issues soon. It might be better to make something on github.