Re: Upcoming GLib changes

[Sebastian Wilhelmi <wilhelmi ira uka de>]

Hi Tim,

> Owen and me recently went over the new additions in the glib 1.3 branch
> in order to sort out what realy should be in there and to reveal code
> portions that still need some work to be certified as clean and
> elegant GLib code ;)
> we discovered that we actually had a bunch of issues with the current
> stuff in the development tree, and in order to bring GLib 1.3 up to speed,
> i'll merge all the pending bug fixes from 1.2.x in the next few days and
> clean up various parts of the new API. the following is a summary of our
> concerns with the current CVS version.
> 
> the random number generator (Mersenne Twister)
> ----------------------------------------------
> 
> 1) at this point, we do not want glib to depend on libm.so, so
>    the g_rand_normal() implementation should vanish from the grand.c

That's what I thought, that's why it still is disabled so far. I'll remove it.

> 2) the current random number implementation provides two sets of interfaces.
> 
>    one uses a context structure (containing some state information to
>    produce the next random number) to allow multiple streams of repeatable
>    random numbers, and works well in a threaded environment with no lock
>    overhead.
> 
>    The other one is built on top of this and uses a single global context
>    for a simplified interface. This simplified interface works
>    like the old-fashioned unix rand() and srand() functions, using a global
>    lock for thread safety.
> 
>    there was disagreement over whether the second interface was necessary.
>    i liked it, but Owen and Federico thought it was confusing and unecessary
>    bloat.
>    so, to help resolve the issue we thought we'd ask what other people on
>    gtk-devel-list think.

Being the one, who wrote this, I might be a bit biased ;-), but I think both
situations are important and worth being supported, the second interface being
a mere convenience, but without that I doubt, anyone would use this generator
at all, if he just needed a few numbers, or take the case, where you need
random numerbs in a function. You would need another static or another
parameter, both of which is not necessary. I agree however, that the naming
g_rand_* and g_random_* might be a bit confusing.
 
Bye,
Sebastian
-- 
Sebastian Wilhelmi                   |            här ovanför alla molnen
mailto:wilhelmi@ira.uka.de           |      är himmlen så förunerligt blå
http://goethe.ira.uka.de/~wilhelmi   |