# Ticket #11457(new enhancement)

Opened 2 years ago

## Witt Vectors

Reported by: Owned by: tdupu roed major sage-5.10 padics witt vectors, padic, rings N/A Taylor Dupuy, David Roe

### Description

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

## Change History

### comment:1 Changed 2 years ago by 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'
```

### comment:2 Changed 2 years ago by kcrisman

• Owner changed from tbd to roed

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.

### comment:3 Changed 2 years ago by 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

### Changed 4 months ago by tdupu

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

### comment:4 Changed 4 months ago by 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)()

219         a = self.dict
220         b = other.dict
--> 221         return C(wittprod(self.p,a,b), self.parent() )
222
223     def frob(self):

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

### Changed 4 months ago by tdupu

Hopefully I'm using mercurial right...

### comment:5 follow-up: ↓ 6 Changed 4 months ago by 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?

### comment:6 in reply to: ↑ 5 ; follow-up: ↓ 7 Changed 4 months ago by tdupu

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.

### comment:7 in reply to: ↑ 6 Changed 4 months ago by 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?

### comment:8 Changed 3 months ago by 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").

Last edited 3 months ago by darij (previous) (diff)

### comment:9 Changed 3 months ago by 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.

### comment:10 Changed 3 months ago by 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.

### comment:11 Changed 3 months ago by 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}(ap) + pn 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.

Note: See TracTickets for help on using tickets.