Computing directly on the field elements is hacking the
abstractions
of VIFF. 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 think we are in agreement: public methods on the runtimes will
keep
returning Shares. Methods used internally in runtimes can return
other
things as needed. To me it sounds like a better API to require
preprocessing functions to return a list of Deferreds:
[D(?), D(?), ...],
instead of a Deferred list of tuples containing Deferreds :-)
I think it will simplify the interface nicely, at least for
consumers.
Using simpler types also leads to less memory usage which has a
positive
effect on performance, as Marcel notes. So let's go for it.
So this makes 2 votes in favour of it and 1 against it. Maybe we
should have a meeting to discuss it. What do you think?
I can agree on this as well, as long as we don't make field
elements canonical.
You mean that the preprocessing infrastructure should not be
restricted to FieldElements but can handle other items such as the
tuples used by the Orlandi runtime. Is that correct? It was never my
plan to introduce this restriction. I just want to get rid of the
Deferreds in the preprocessing pool because I think that they are
unnecessary there.
Then by all means go ahead and speed up the preprocessing. :)
____________________________________________________
Janus Dam Nielsen
Research and Innovationspecialist, PhD.
CENTRE FOR IT-SECURITY
THE ALEXANDRA INSTITUTE LTD.
T +45 42 22 93 56
E [email protected]
W alexandra.dk
____________________________________________________
_______________________________________________
viff-devel mailing list (http://viff.dk/)
[email protected]
http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
