Added a distributed alias table to YGM. #256
Conversation
There was a problem hiding this comment.
I recommend making use of concepts in the way they are used in existing container base classes. We can decide where to move these concepts and new ones to add independent of this PR.
The existing constructors look good, but constructors that work from STL containers should be added as well.
| concept convertable_to_double = std::convertible_to<T,double>; | ||
|
|
||
| template<typename T> | ||
| concept is_pair = requires { |
There was a problem hiding this comment.
Can try to use the existing DoubleItemTuple here. This will be satisfied by std::pair and std::tuple with two items. To make this general, you can access elements using std::get.
There was a problem hiding this comment.
Forgot about this, but we have a checker for std::pair that could be turned into a concept as well.
| } | ||
|
|
||
| template<typename Container> | ||
| requires is_associative_container<Container> && |
There was a problem hiding this comment.
Having a concept for checking if a container is an associative container is good, but I don't think it's what is needed here. What is needed here is the presence of a for_all argument and a check that types are appropriate (same as is currently done here).
The code that you have written can build an alias_table from a ygm::io::line_parser (probably requires a .transform() method to be really useful), but this is not a container at all.
I recommend modeling this off of the base_batch_erase functionality I linked to for now. We can re-evaluate the concepts we should make use of in a future PR.
| }; | ||
|
|
||
| template<typename T> | ||
| concept is_value_container = requires { |
There was a problem hiding this comment.
std::vector will satisfy this concept. Checking for the presence of for_all_args (using HasForAll) and then probing it for the number of items within the for_all_args tuple could work, but this would also be satisfied by the ygm::io::line_parser.
Checking these things might be a little complicated generically. We may have to write a very targeted concept that checks the container_type to get what we want.
| }; | ||
|
|
||
|
|
||
| template <typename item_type, typename RNG> |
There was a problem hiding this comment.
There's no written rules about this, but try emulating the use and style of template parameters and aliases already in use; the ygm::container::bag is a good example. The template parameters are capitalized to make it clear they are specifically template parameters (and not the name of some struct we have elsewhere). Create a public alias for types that are likely to be useful outside of the class itself so they can be inspected.
| item_type b; | ||
|
|
||
| template <typename Archive> | ||
| void serialize(Archive& ar) { // Needed for cereal serialization |
There was a problem hiding this comment.
I don't think you're ever serializing a table_item.
| template <typename Visitor, typename... VisitorArgs> | ||
| void async_sample(Visitor visitor, const VisitorArgs &...args) { // Sample should be provided a lambda/functor that takes as an argument the item type | ||
|
|
||
| auto sample_wrapper = [](auto ptr_MAT, const VisitorArgs &...args) { |
There was a problem hiding this comment.
ptr_MAT looks like it should stand for "pointer to multi-alias table", which this isn't.
| build_alias_table(); | ||
| m_local_items.clear(); | ||
| } | ||
|
|
There was a problem hiding this comment.
What about constructing from local STL containers?
alias_tabledata structure to ygm. Alias table data structure enables O(1) sampling time from a discrete distribution.alias_table::async_samplewhich requires the user provide a lambda that takes the item sampled as an argument.ygm::randomwhere thedefault_random_enginenow sits as well asalias_table