On Feb 15, 10:12 am, Robert Bradshaw <[EMAIL PROTECTED]> wrote: > On Feb 14, 2008, at 8:44 PM, Carl Witty wrote: > > [...] > > > > > randstate_python() > > Returns an instance of random.Random. The first time it is called > > on a given instance of randgen, a new random.Random is created and > > seeded from the gmp_randstate_t; this is saved, and subsequent > > calls > > return the same random.Random instance. > > ... There will be similar methods for every subsystem of the first > > kind > > (with separate random state objects) (if there are any more, other > > than > > Python). > > > set_seed_libc(force=False) > > set_seed_ntl(force=False) > > set_seed_pari(force=False) > > set_seed_magma(force=False) > > set_seed_mathematica(force=False) > > set_seed_...() > > Sets the seed of the specified random number generator, from a new > > random number from the gmp_randstate_t. > > > Whenever library code is about to use a generator, it should call > > the corresponding method. > > Rather than requiring library code to call these functions, I think > all relevant seeds/states should be set on creation/reseeding of a > randgen object. Then library code can operate under the assumption > that the needed random states are initialized and ready to be used at > any time. For interfaces, it would just store the random seed to be > retrieved when the interface starts up if an interface is not yet > running.
I don't like it... that would make switching randgens much more expensive. With my version, I expect that creating a randgen would cost <40 microseconds, and that switching randgens would be essentially free. With your version, switching randgens probably costs >1ms per interface, so could easily be 100 times more expensive than my version. (These estimates are based on some simple experiments on my laptop, a fast Linux machine.) Also, preemptively seeding reduces the isolation. Suppose that we can reseed Mathematica's generator, but not extract the current state. (I have no idea if that's true of Mathematica, but it's probably true of at least one of our interfaces.) If somebody is using Mathematica (including Mathematica random numbers) in conjunction with Sage library code, then my version provides perfect isolation as long as the Sage code does not call .set_seed_mathematica(); your version reseeds Mathematica if the Sage code switches randgens for any reason. Note that only the lowest-level call would need to worry about calling .set_seed_...(); for instance, ntl_ZZ_p_random_element() would call .set_seed_ntl(), so its callers wouldn't have to do so (and in fact, would not even have to know about the randgen framework). My guess is that there would end up being less than a hundred .set_seed_...() calls throughout Sage. > That being said, I think this is a good proposal. Thanks! > - Robert Carl --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
