IWRunNode vs MultiValuedRunNode: The biggest differences between the two classes lie in code which was commented out and I deleted. Other than that, the real difference (and subtle) I see is that the attribute _nov_2_pairs needs to be defined differently in either class. For the former, is a table of pairs of AtomIdx, in the latter a pair of Width1Tuple a type which is imported from lapkt::novelty and defined around the language type we represent our datums (FSFeatureValueT)..
SimulationEvaluator vs MultiValuedSimulationEvaluator: the major difference between the two classes is in the implementation of the method reached_atoms(). In both classes it is defined as const, but it has different return types: std::vector<bool> vs. std::vector<Width1Tuple>. This is important: the former assumes datums are booleans, the latter assumes datums to be FSFeatureValueT. Also a convenience accessor to the set of features associated with the evaluator has been added to the interface of MultiValuedSimulationEvaluator.
IWRun::Config vs MultiValuedIWRun::Config: the attribute mark_negative has been removed from the latter as it doesn't make sense in the context of the second class. Three new attributes have been added to the latter, _R_file and _log_search activate the code that allows to load the R set from a file, and the code that logs the IW search tree into a JSON document. _filter_R_set is no longer used: I did some experimentation with doing some "post processing" on the R-set, without much success.
MultiValuedIWRun::DeactivateZCC class added to track option to ignore state constraints during the IW(k) lookahead. The term "zero crossings" refers to allowing IW to shoot through the "holes" in the state space created by state constraints.
IWRun vs MultiValuedIWRun: quite a few changes
The attribute _visited has been added to MultiValuedIWRun to store the set of states visited during the lookahead.
MultiValuedIWRun::mark_tuples_in_path_to_subgoal(): Important changes here, as first, datums are no longer boolean, and rather than accessing state variables directly, we use the feature set in the evaluator.
MultiValuedIWRun::mark_all_tuples_in_path_to_subgoal: Analogous changes to the above.
MultiValuedIWRun::compute_R_all(): Method has been disabled with an exception.
MultiValuedIWRun::compute_R(): Added code to load R-set from file.
MultiValuedIWRun::compute_plain_RG2(): Added check for goal_directed flag, if false, extract_R_1 is called.
MultiValuedIWRun::compute_plain_R1(): Changed return type to match that of the datums.
MultiValuedIWRun::load_R_set(): Loads the R set from a file.
MultiValuedIWRun::filter_R_set(): Experiments with R-set filtering, no longer used.
MultiValuedIWRun::compute_coupled_features(): Added toIWRun because of static polymorphism. Method used in experiments filtering R-set, no longer used.
MultiValuedIWRun::dump_R_set(): Code to dump the R-set to a file.
MultiValuedIWRun::extract_R_1(): Changed return type to match that of datum.
MultiValuedIWRun::compute_adaptive_R(): Changed return type to match that of datum.
MultiValuedIWRun::extract_R_G(): Added code to dump R set to file, changed return type to match that of the datum.
MultiValuedIWRun::extract_R_G_1(): Idem as MultiValuedIWRun::extract_R_G().
`MultiValuedIWRun::run(): added code to check if IW(k) lookahead needs to respect state constraints, uses this info to influence the behaviour of the applicable action iterators.
`MultiValuedIWRun::report(): added code to store the search tree that follows from IW(k) into a file.
Summary
The filtering of R sets and its associated methods need to be moved out of the class. I would like to have them somewhere, as a snippet of some sort and a note, since the idea of post-processing R-sets may have some potential.
The rest of the changes are related to switching the underlying datum used to compute w(s) from bool to FSFeatureValueT (which is unsigned), and that we need to use the features to obtain the relevant valuations.
iw_run
andmv_iw_run
could probably be merged back to reduce a lot of code duplication. See some good notes by @miquelramirez on this here: https://github.com/aig-upf/fs-private/issues/91#issuecomment-335436577. I'm copying them verbatim below:IWRunNode
vsMultiValuedRunNode
: The biggest differences between the two classes lie in code which was commented out and I deleted. Other than that, the real difference (and subtle) I see is that the attribute_nov_2_pairs
needs to be defined differently in either class. For the former, is a table of pairs ofAtomIdx
, in the latter a pair ofWidth1Tuple
a type which is imported fromlapkt::novelty
and defined around the language type we represent our datums (FSFeatureValueT
)..SimulationEvaluator
vsMultiValuedSimulationEvaluator
: the major difference between the two classes is in the implementation of the methodreached_atoms()
. In both classes it is defined asconst
, but it has different return types:std::vector<bool>
vs.std::vector<Width1Tuple>
. This is important: the former assumes datums are booleans, the latter assumes datums to beFSFeatureValueT
. Also a convenience accessor to the set of features associated with the evaluator has been added to the interface ofMultiValuedSimulationEvaluator
.IWRun::Config
vsMultiValuedIWRun::Config
: the attributemark_negative
has been removed from the latter as it doesn't make sense in the context of the second class. Three new attributes have been added to the latter,_R_file
and_log_search
activate the code that allows to load the R set from a file, and the code that logs the IW search tree into a JSON document._filter_R_set
is no longer used: I did some experimentation with doing some "post processing" on the R-set, without much success.MultiValuedIWRun::DeactivateZCC
class added to track option to ignore state constraints during the IW(k) lookahead. The term "zero crossings" refers to allowing IW to shoot through the "holes" in the state space created by state constraints.IWRun
vsMultiValuedIWRun
: quite a few changes_visited
has been added toMultiValuedIWRun
to store the set of states visited during the lookahead.MultiValuedIWRun::mark_tuples_in_path_to_subgoal()
: Important changes here, as first, datums are no longer boolean, and rather than accessing state variables directly, we use the feature set in the evaluator.MultiValuedIWRun::mark_all_tuples_in_path_to_subgoal
: Analogous changes to the above.MultiValuedIWRun::compute_R_all()
: Method has been disabled with an exception.MultiValuedIWRun::compute_R()
: Added code to load R-set from file.MultiValuedIWRun::compute_plain_RG2()
: Added check forgoal_directed
flag, if false,extract_R_1
is called.MultiValuedIWRun::compute_plain_R1()
: Changed return type to match that of the datums.MultiValuedIWRun::load_R_set()
: Loads the R set from a file.MultiValuedIWRun::filter_R_set()
: Experiments with R-set filtering, no longer used.MultiValuedIWRun::compute_coupled_features()
: Added toIWRun
because of static polymorphism. Method used in experiments filtering R-set, no longer used.MultiValuedIWRun::dump_R_set()
: Code to dump the R-set to a file.MultiValuedIWRun::extract_R_1()
: Changed return type to match that of datum.MultiValuedIWRun::compute_R_g_prime()
: $R_{all}$ fallback disabled.MultiValuedIWRun::compute_adaptive_R()
: Changed return type to match that of datum.MultiValuedIWRun::extract_R_G()
: Added code to dump R set to file, changed return type to match that of the datum.MultiValuedIWRun::extract_R_G_1()
: Idem asMultiValuedIWRun::extract_R_G()
.`MultiValuedIWRun::run()
: added code to check if IW(k) lookahead needs to respect state constraints, uses this info to influence the behaviour of the applicable action iterators.`MultiValuedIWRun::report()
: added code to store the search tree that follows from IW(k) into a file.Summary
The filtering of R sets and its associated methods need to be moved out of the class. I would like to have them somewhere, as a snippet of some sort and a note, since the idea of post-processing R-sets may have some potential.
The rest of the changes are related to switching the underlying datum used to compute w(s) from
bool
toFSFeatureValueT
(which isunsigned
), and that we need to use the features to obtain the relevant valuations.