On Wed, Jan 04, 2012 at 06:56:11PM +0100, Damien Doligez wrote: > On 2012-01-02, at 02:43, oliver wrote: > > > If the type is an abstract type, which comes from something like > > Hashtbl.Randomseed > > and has type t, not type int, this problem would vanish. > > You have to be careful. If we make hash table randomization mandatory, > the Frama-C people will hate us, as will all the people who want > reproducible results from their programs (for purposes of testing and > benchmarking, for example). [...]
I did not meant it must be mandatory. But provide a way, that makes it easy to use randomization and not-so-easy to use the always-same values e.g. for testing puroposes. If it needs extra effort to make simple seed values, people would prefer the randomized ones, if not they want to write some extra code (maybe applying a functor). > > So, even if randomized is the default, there must be a way to get a > plain hash table that does the same thing every time. Yes, of course. But maybe it should not be encouraged, and the programmer-in-a-hurry would use ready-to-use random initializations, which are provided by the Hashtbl-module and the one who needs it non-randomized would need to write his own addition then. Then the lazy programmer goes safe and the unsafe way needs extra effort. Nevertheless I think optional int value as a first fix would also be ok. And maybe some of you remember the Debian random-device bug (some years ago), where the random-device under certain circumstances ran out of entropy.... So in any case it needs to be possible to change the random generator. But pseudo-random is always a compromise. Who really needs true random should of course use special hardware that creates wide bandwith noise and uses an ADC to sample the signal. Ciao, Oliver -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
