- loaded_die.cpp example of random sampling with replacement of unequally weighted objects
- advanced_dice.cpp roll a set of three dice using only one call to the random number generator
- cards.cpp cards are drawn from a deck, returned to the deck, and drawn again.
- multiple_distributions.cpp Use several different distributions to access a given set of items.
- custom_generator.cpp Example of specifying a user-designed custom random number generator.
- near_max.cpp Usually draw maximum valued item, but with some diminishing probability for further down the list.
- monster_drops.cpp get a couple random treasures from a master list, depending on monster level and type.
- fuzzy_logic.cpp It's 68 degrees fahrenheight in here; is it hot, fine, or cold?
- game_theory.cpp NPC makes a choice using a mixed strategy, so that it won't be predictable.
- bernoulli_process.cpp Simulate five trucks leave a warehouse, each with a 40% independent chance of being late.
- random_actions.cpp Choose a course of action based on preference and availability.
- stochastic_approximation.cpp AI learns to predict an unknown behavior pattern, with overall improving results, and scores it's performance.
C++ hat random container
Hi,
I've developed a handy STL-style container for storing and retrieving items randomly. Items can have different probabilities, and can either be removed from the set like cards from a deck, or come up again like rolling dice.
hat.h hat container source code, revision 1.59
The C++ hat random container online documentation
hat.DevPak package for those using dev-cpp. Installs hat.h in [dev-cpp]/include, and a bunch of example programs in [dev-cpp]/Examples/Hat.
Some example uses (updated):
Very interesting, i have a couple of suggestions to improve it a bit.
1. in your template arguments for hat i would also add another type parameter an allocator type that defaults to standard allocator type that allows clients to choose non default allocators, you pass this to your vector & list type parameters.
2. your non type parameter the function pointer i would turn this into a type parameter and make your default random function into some kind of functor (functional object usually overloads the function call operator i.e "()").
3. Your missing a const_iterator type.
3. Small detail but important still, your missing some typedefs in your hat type & iterator type that are required for STL, also in your iterator types provide a typedef of which iterator_category it is.
4. I briefly glanced at the concept of hat but it looks like hat could be an adaptor type more than a first class constainer if thats the case consider whether or not if the vector of nodes or list of Ts could be replaced with other STL containers if it is then you could add another template type parameter that is a template template type paramter that has a default type but clients can try different containers to see if they get better results (this cost you nothing, power 2 static polymorphism!).
I think thats everything at the moment but if i think of anything else i'll let you know.
1. in your template arguments for hat i would also add another type parameter an allocator type that defaults to standard allocator type that allows clients to choose non default allocators, you pass this to your vector & list type parameters.
2. your non type parameter the function pointer i would turn this into a type parameter and make your default random function into some kind of functor (functional object usually overloads the function call operator i.e "()").
3. Your missing a const_iterator type.
3. Small detail but important still, your missing some typedefs in your hat type & iterator type that are required for STL, also in your iterator types provide a typedef of which iterator_category it is.
4. I briefly glanced at the concept of hat but it looks like hat could be an adaptor type more than a first class constainer if thats the case consider whether or not if the vector of nodes or list of Ts could be replaced with other STL containers if it is then you could add another template type parameter that is a template template type paramter that has a default type but clients can try different containers to see if they get better results (this cost you nothing, power 2 static polymorphism!).
I think thats everything at the moment but if i think of anything else i'll let you know.
Ouw nice! Thank you! :) I just tried it... works great! :)
I am going to use it for my random item drops( monsters drop items )
I am going to use it for my random item drops( monsters drop items )
Quote:4. I briefly glanced at the concept of hat but it looks like hat could be an adaptor type more than a first class constainer if thats the case consider whether or not if the vector of nodes or list of Ts could be replaced with other STL containers if it is then you could add another template type parameter that is a template template type paramter that has a default type but clients can try different containers to see if they get better results (this cost you nothing, power 2 static polymorphism!).
The hat is different from available STL containers in both it's operational specification, and it's implementation; it isn't possible to modify the functionality of vectors or lists to acheive it.
Edit: It is a non-sequential associative container, keyed on probability weights. The keys (as well as the values) are not necessarily unique, and can change during run-time.
It's iterators remain valid after an insert/delete--a thing vectors cannot do. It also can look up an element in O(log n) time--a thing lists cannot do. And it can delete any element from it's set--a thing heaps cannot do. And these are the main operations of any container; insert, delete, and search.
Thank you for your observations on what is needed yet; I'm working on the iterator category and const_iterator for the next revision.
[Edited by - AngleWyrm on September 2, 2004 2:27:22 PM]
Quote:Original post by AngleWyrm
Thank you for your observations on what is needed yet; I'm working on the iterator category and const_iterator for the next revision.
No probs, what about 1 & 2 [smile] i could give a quick example of what i was talking about.
Have you considered integrating with boost::random (or even to submit your class to Boost -- they'll dissect it more carefully than we can [smile])?
What are the exception guarantees of your class? What happens during, say, a pull(), if the element's copy operation throws an exception?
What are the exception guarantees of your class? What happens during, say, a pull(), if the element's copy operation throws an exception?
Quote:Original post by Fruny
Have you considered integrating with boost::random
if you go for this, this would probably intail suggestion 2, changing your non-type parameter to a type parameter (the one that you have as function pointer currently).
Quote:Original post by rakoon2
Ouw nice! Thank you! :) I just tried it... works great! :)
I am going to use it for my random item drops( monsters drop items )
Welcome! Glad it's workin' for ya.
Quote:Original post by Fruny
Have you considered integrating with boost::random (or even to submit your class to Boost -- they'll dissect it more carefully than we can [smile])?
Edit:Yes, I submitted it to the boost mailing list, but the only responses I got from those guys were two comments about my username, and no observations about the code. The second commenter "seconded" the first commenter, commitee meeting style. Complete waste of neurons.
I had thought of the boost::random library when I first designed the optional user-specified custom RNG. Except I haven't seen boost::random code that can perform this one simple feat:
// produce a random number from a range specified at run-timefor ( int range = 3; range < 10; range++ ){ // return random number in the range [0, range) cout << random(range) << endl;}
(Edit: that glaring white background was killing me.)
Any example boost::random code would help.
-:|:-
AngleWyrm
[Edited by - AngleWyrm on September 2, 2004 3:09:11 AM]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement