I thing to consider. Does it make sense to run all unit tests with the same configuations of players and thresholds. That is, for all protocols p, is p executed with x players and threshold t is p welldefined?
I suspect, out of the blue air, that this is not the case. I am I right or am I wrong? -- Janus Den 13/02/2008 kl. 8.43 skrev Martin Geisler: > "Thomas Jakobsen" <[EMAIL PROTECTED]> writes: > >> I suggest that we - as far as it's reasonable - write unit tests >> that don't depend on a specific number of players and threshold, but >> instead use number of players and threshold as defined by >> runtime.threshold and runtime.players. This will allow us to >> automatically run these tests with many combinations of (no of >> players, threshold), say, (3,1), (5,2), (5,1), (7,3). > > That is an excellent idea! You're right that the current unit tests > are hard-coded to use a particular number of players (3 player for > most of tests and 4 for the Bracha broadcast test). We should change > this and make a setup where the same test is run with different > parameters. > > Changing it is quite easy (but somewhat tedious): > > a, b, c = runtime.shamir_share([1, 2, 3], self.Zp, 42 + > runtime.id) > > becomes > > everybody = range(1, len(runtime.players)+1) > shares = runtime.shamir_share(everybody, self.Zp, 42 + > runtime.id) > > and we can then loop over shares as we see fit. I think I will make a > num_players field in Runtime so that we can stop writing > len(runtime.players) so often... > > One can almost just use runtime.players.keys(), but since > runtime.players is a dictionary we don't really know in which order > the keys will come out, or more importantly, if the order is the same > for all players. > >> My experience from developing protocols for the previous SIMAP >> prototype was that testing all protocols with (3,1), (5,1) (5,2) and >> (7,3) sometimes caught subtle bugs that wouldn't have been caught >> when testing only (3,1) and, say, (5,2). > > Yeah, there might be some strange bugs hiding there... > > I think we should do this after a 0.4 release. There has been quite a > lot of new features since 0.3: some asymmetric protocols, Bracha > broadcast, xor overloading. When we have asymmetric open and > prss_share, then I think we should release the code as VIFF 0.4. > > -- > Martin Geisler > _______________________________________________ > viff-devel mailing list (http://viff.dk/) > viff-devel@viff.dk > http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk _______________________________________________ viff-devel mailing list (http://viff.dk/) viff-devel@viff.dk http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
