[random]how to initialise a rng for use in the initialiser list?
Hello again, sorry for the many questions to this list right now, I'm just beginning to use boost. This time I have some issues regarding the boost.random usage. I have used it just fine for many examples but there's one tricky bit that I was wondering whether anyone of you knows a solution for. I use a class which keeps the random number generator around as a member variable; this class also has a const matrix. Now in the constructor of the class I do something like: my_class::my_class(args) : rng(seed), matrix(initialise()), ... { ... } Of course, I want to use the rng to initialise the matrix and that's where things fail. I guess, I could use a different rng just to fill the matrix, or make it non-const and fill it in the constructor body. But does anyone know a neat trick to do this in the way proposed? Thank you for any answers, Moritz
Moritz Beber wrote:
I use a class which keeps the random number generator around as a member variable; this class also has a const matrix. Now in the constructor of the class I do something like:
my_class::my_class(args) : rng(seed), matrix(initialise()), ... { ... }
Of course, I want to use the rng to initialise the matrix and that's where things fail. I guess, I could use a different rng just to fill the matrix, or make it non-const and fill it in the constructor body. But does anyone know a neat trick to do this in the way proposed?
This might not be the best way, but you need to at least ensure that the rng member of the class is declared before the matrix (in the class declaration.) Sorry if this doesn't, in fact, answer you problem. -yzt
class my_class {
Hi For this kind of stuff, when complex objects have strong interrelationships at startup, I prefer usually to "delay" (not the proper word, I guess) the initiliazation of material within the class in this way: private: long __seed; // I always keep tracks of the seed I use in RNPG stuff rng_t * __rng; // note here i use a dynamically allocated instance matrix_t __matrix // could do the same here but it depends on the pb... rng_t & rng () { if ( __rng == 0) throw "Ooops!"; return *__rng; } void initialise () { // do something useful using 'rng ()'... } void __init () { __rng = new my_rng_t (__seed); // do whatever initialization you need here... __matrix.initialise (); // more init... } void __del () { if (__rng != 0) delete __rng; __rng = 0; // clean other stuff... } public: my_class (long seed_) : __rng (0) //, __matrix (DEFAULT CTOR PARAMETERS) { __seed = seed_; __rng = 0; __init (); } ~my_class () { __del (); } ... }; <<< But it is matter of preference... and maybe you don't want to use dyn. alloc. for the '__rng' field. It also enables to reuse this kind of object using proper public "reset ()" and "init (long?)" methods... Using some 'rng_t' virtual base PRNG class (if available) allows you to easily allocate another kind of generator... Hope it can help. regards frc -- Francois Mauger Laboratoire de Physique Corpusculaire de Caen et Universite de Caen ENSICAEN - 6, Boulevard du Marechal Juin, 14050 CAEN Cedex, FRANCE e-mail: mauger@lpccaen.in2p3.fr
Moritz Beber wrote:
I use a class which keeps the random number generator around as a member variable; this class also has a const matrix. Now in the constructor of the class I do something like:
my_class::my_class(args) : rng(seed), matrix(initialise()), ... { ... }
Of course, I want to use the rng to initialise the matrix and that's where things fail. I guess, I could use a different rng just to fill the matrix, or make it non-const and fill it in the constructor body. But does anyone know a neat trick to do this in the way proposed?
This might not be the best way, but you need to at least ensure that the rng member of the class is declared before the matrix (in the class declaration.)
Sorry if this doesn't, in fact, answer you problem. -yzt
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Dear members, using the graph concepts for a case where I frequently add or remove edges I came across an inconsistency: removing an edge may invalidate the edge counter because it does not check whether the edge existed or not. This is the code from the header file boost/graph/adjacency_matrix.hpp: template <typename D, typename VP, typename EP, typename GP, typename A> void remove_edge(typename adjacency_matrix<D,VP,EP,GP,A>::vertex_descriptor u, typename adjacency_matrix<D,VP,EP,GP,A>::vertex_descriptor v, adjacency_matrix<D,VP,EP,GP,A>& g) { --(g.m_num_edges); detail::set_edge_exists(g.get_edge(u,v), false, 0); } Whereas in the case of adding an edge the check is done: template <typename D, typename VP, typename EP, typename GP, typename A> std::pair<typename adjacency_matrix<D,VP,EP,GP,A>::edge_descriptor, bool> add_edge(typename adjacency_matrix<D,VP,EP,GP,A>::vertex_descriptor u, typename adjacency_matrix<D,VP,EP,GP,A>::vertex_descriptor v, const EP& ep, adjacency_matrix<D,VP,EP,GP,A>& g) { typedef typename adjacency_matrix<D,VP,EP,GP,A>::edge_descriptor edge_descriptor; if (detail::get_edge_exists(g.get_edge(u,v), 0) == false) { ++(g.m_num_edges); detail::set_property(g.get_edge(u,v), ep, 0); detail::set_edge_exists(g.get_edge(u,v), true, 0); return std::make_pair (edge_descriptor(true, u, v, &detail::get_property(g.get_edge(u,v))), true); } else return std::make_pair (edge_descriptor(true, u, v, &detail::get_property(g.get_edge(u,v))), false); } I would suggest a similar check for "remove_edge" instead of blindly counting down. Regards, Moritz
using the graph concepts for a case where I frequently add or remove edges I came across an inconsistency: removing an edge may invalidate the edge counter because it does not check whether the edge existed or not. This is the code from the header file boost/graph/adjacency_matrix.hpp:
template <typename D, typename VP, typename EP, typename GP, typename A> void remove_edge(typename adjacency_matrix<D,VP,EP,GP,A>::vertex_descriptor u, typename adjacency_matrix<D,VP,EP,GP,A>::vertex_descriptor v, adjacency_matrix<D,VP,EP,GP,A>& g) { --(g.m_num_edges); detail::set_edge_exists(g.get_edge(u,v), false, 0); }
That definitely looks like a problem. Can I get you to file a ticket for it on svn.boost.org? I can address the issue on monday. Andrew Sutton andrew.n.sutton@gmail.com
using the graph concepts for a case where I frequently add or remove
edges I came across an inconsistency: removing an edge may invalidate the edge counter because it does not check whether the edge existed or not. This is the code from the header file boost/graph/adjacency_matrix.hpp:
template <typename D, typename VP, typename EP, typename GP, typename A> void remove_edge(typename adjacency_matrix<D,VP,EP,GP,A>::vertex_descriptor u, typename adjacency_matrix<D,VP,EP,GP,A>::vertex_descriptor v, adjacency_matrix<D,VP,EP,GP,A>& g) { --(g.m_num_edges); detail::set_edge_exists(g.get_edge(u,v), false, 0); }
That definitely looks like a problem. Can I get you to file a ticket for it on svn.boost.org? I can address the issue on monday.
Fixed in trunk. Andrew Sutton andrew.n.sutton@gmail.com
participants (4)
-
Andrew Sutton -
François Mauger -
Moritz Beber -
Yaser Zhian