Setting this to in-progress since we do have a patch, now we just need
it fine-tuned.

It's been a week -- does anyone want to push forward on this?

Sigurd has posted a patch for this here:

 
http://lists.viff.dk/pipermail/viff-devel-viff.dk/2008-September/000459.html

I would like to see some tests which verify that the result types are
indeed mpz so that we do not accidentally go back to plain integers
without noticing.

I'm classifying this as a bug -- it is most likely a performance bug.

I don't think it should be all too difficult to fix this, one only has
to take care of converting the mpz objects into bytes and back again
when the data is sent over the network. As far as I remember mpz
objects have a method for this.

Other than that, the tricky part is to make sure that all numbers used
in VIFF are converted to mpz objects when we first encounter them. So
the arguments to the overloaded __add__, __mul__, etc. methods of
Share should be converted, as should arguments to shamir_share.

Please write a comment here if any of you wants to look at this.

As described in Msg 82 (Issue 13), GMPY is about twice as fast as plain
Python for small numbers (16-64 bit) and the gap only increases as we
turn to larger numbers. So we should definitely fix this issue.

Make field elements use GMPY unless some option asks them not to.

We used to have two implementations of field elements, one using
Python integers and one using GMPY. At one point way back I removed
the GMPY implementation since it was lacking behind the Python
implementation. But we should introduce it again, but this time as one
class only.