Hmm, I have to admit that I do not fully understand your question. What's the difference between "general" and "RNG" in this context?
RNG speed is quite important but memory requirements are really the issue as every random branching stores all state necessary to recompute the random decisions. Christian -- Christian Schulte, www.ict.kth.se/~cschulte/ From: users-boun...@gecode.org [mailto:users-boun...@gecode.org] On Behalf Of Javier Andrés Mena Zapata Sent: Monday, May 18, 2009 6:32 PM To: gecode user list Subject: Re: [gecode-users] How to set an arbitrary RandomGenerator for randomized branching?!? Hi, Just curiosity... Do you prefer RNG speed, RNG space, general speed or general space? Cheers, On Mon, May 18, 2009 at 2:55 AM, Mikael Zayenz Lagerkvist <zay...@gmail.com> wrote: Hi, Currently it is not possible to exchange the random number generator. Furthermore, the implementation uses properties of the random number generator that would most probably compromise efficiency if they were abstracted away (for example, the state is limited to a single unsigned int as seed). If you want to use your own random number generator, I would suggest writing your own subclasses of ViewSelBase and ValSelbase similar to ViewSelRnd and ValRnd. For curiosity, what is the reason that you want to change the random number generator used? Cheers, Mikael On Sat, May 16, 2009 at 12:37 AM, Martin Mann <mm...@informatik.uni-freiburg.de> wrote: > > Hi everybody, > > I digged a bit into the Gecode source about the randomized branching > supported since version 3. > > In line 124 in gecode/support/random.hpp I found the definition of > RandomGenerator internally used in the view selection: > > http://www.gecode.org/doc-latest/reference/group__FuncSupport.html#g02fe942f 90a57a25639f09960dab4459 > > As given there, it is just a typedef onto the > LinearCongruentialGenerator provided by Gecode but I would like to set > up my own random number generator... > > Is there a possibility to support user defined generators? e.g. in > coming versions? > > If not available right now, maybe you like the following suggestion: > > A possibility would be a super class 'RNG' that has to be implemented by > every generator plus a kind of factory class 'RNF' with static members only. > The RNF would be a wrapper around the current RNG instance to use > (stored in a static internal member). Thus, all Gecode internals that > need a random number use a static interface of RNF instead of some RNG > instance members. So the library gets independent of the concrete RNG > used and you get the possibility to register a user defined RNG within > the RNF. Per default the RNF can use the linear congruential generator > provided. The static interface and data member would avoid annoying > copies of RNGs all around and won't complicate your Gecode internals/source. > > > Just a suggestion... if it is already possible just ignore and please > let me know how to do with the current Gecode version. :) > > > Have a nice weekend, > > Martin > > > _______________________________________________ > Gecode users mailing list > us...@gecode.org > https://www.gecode.org/mailman/listinfo/gecode-users > -- Mikael Zayenz Lagerkvist, http://www.ict.kth.se/~zayenz/ <http://www.ict.kth.se/%7Ezayenz/> _______________________________________________ Gecode users mailing list us...@gecode.org https://www.gecode.org/mailman/listinfo/gecode-users -- "La buena educación, es lo que nos queda cuando se nos olvida todo lo que nos han enseñado" ¿? Javier Andrés Mena Zapata http://StrategicDecision.net/ +57 (2) 318 1000 ext. 2910 Cali - Colombia
_______________________________________________ Gecode users mailing list us...@gecode.org https://www.gecode.org/mailman/listinfo/gecode-users
