Hi Janus,
I am not opposed to your suggestion. However I would like to point out
that in VIFF you compute on shares and not field elements!. Computing
directly on the field elements is hacking the abstractions of VIFF.
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 Share
can be useful as an optimization, however this optimization should be
confined within applications or runtimes, and should not progress over
interface 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
