Hi Janus,

I am not opposed to your suggestion. However I would like to point outthat in VIFF you compute on shares and not field elements!. Computingdirectly on the field elements is hacking the abstractions of VIFF.

## Advertising

`I don't think so. Since I work with VIFF, it treats field elements as`

`they would be shares with threshold 0. You can multiply and add field`

`elements and shares. Furthermore, if you open to shares and multiply`

`them, VIFF doesn't multiply locally, but executes the multiplication for`

`shares of higher threshold. You have to do the following to achieve`

`local multiplication:`

a = open(share_a) b = open(share_b) c = gather_shares([a, b]) c.addCallback(lambda (a, b): a * b)

`Therefore, I think that VIFF computes on field elements as well as on`

`shares almost equally.`

Computation on field elements or rather the representation of a Sharecan be useful as an optimization, however this optimization should beconfined within applications or runtimes, and should not progress overinterface boundaries as I fear you are suggesting.

`I believe that if you would implement an OrlandiTuple class and overload`

`operators there with the current _plus, _minus, and _const_mul`

`functions, the OrlandiRuntime could reuse the add, sub, and lin_comb`

`functions from PassiveRuntime and maybe even the mul function from`

`BasicActiveRuntime. The OrlandiTuple would then be something equivalent`

`to a FieldElement in the older runtimes.`

Best regards, Marcel _______________________________________________ viff-devel mailing list (http://viff.dk/) viff-devel@viff.dk http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk