You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are many places in the codebase where we zip or index through two vectors, adding one to the other. We could write blanket implementations of Add and AddAssign on vectors of field elements to get rid of some boilerplate. These could also check that the lengths of the addend vectors are equal, and panic otherwise to be defensive.
Good point. Implementing it on OutputShare and AggregateShare sounds good. We could also go through and replace for loops adding field vectors with calls to appropriate private helper functions.
I decided to not implement Add and AddAssign for OutputShare and AggregateShare, since the Aggregator API already facilitates arithmetic on these. I suppose we could simplify the implementations of our concrete VDAFs a little, but I didn't bother.
vec_assign_vector(a, b) panics if a is longer than b, but not if b is longer than a. The reason is that I wanted to be able to let b be an iterator, and there are cases where the iterator has infinite about. For example, in Prio3, b is a Prng. As far as I can tell, enforcing the length of b would require an allocation here, but I could be wrong.
There are many places in the codebase where we zip or index through two vectors, adding one to the other. We could write blanket implementations of
Add
andAddAssign
on vectors of field elements to get rid of some boilerplate. These could also check that the lengths of the addend vectors are equal, and panic otherwise to be defensive.See: #300 (comment)
The text was updated successfully, but these errors were encountered: