Implements voting ensemble selection step in sequential search type of methods to possibly improve robustness and stability of feature selection result.
More...
|
|
typedef Sequential_Step< RETURNTYPE, DIMTYPE, SUBSET, CRITERION > | parent |
| | base class alias
|
|
typedef std::shared_ptr< CRITERION > | PCriterion |
| | shared pointer to the single criterion passed into evaluate_candidates() and used to (re-)score the winning subset – distinct from the ensemble member criteria
|
|
typedef std::shared_ptr< Criterion< RETURNTYPE, SUBSET > > | PAbstractCriterion |
| | shared pointer to one ensemble member, held via the abstract Criterion base so unrelated (filter/wrapper) criterion types can be mixed in one ensemble
|
|
typedef std::vector< PAbstractCriterion > | PAbstractCriteria |
| | the ordered collection of ensemble member criteria
|
|
typedef std::shared_ptr< PAbstractCriteria > | PEnsembleCriteria |
| | shared pointer to the ensemble member collection, as supplied to the constructor
|
|
typedef std::shared_ptr< SUBSET > | PSubset |
| | shared pointer to a feature subset
|
|
typedef Candidate_Evaluator< RETURNTYPE, DIMTYPE, SUBSET, Criterion< RETURNTYPE, SUBSET > > | EVALUATORENGINE |
| | typed on the abstract Criterion (the ensemble members' type)
|
|
typedef std::shared_ptr< EVALUATORENGINE > | PEvaluatorEngine |
| | shared pointer to the candidate-evaluation engine (see candidate_evaluator.hpp)
|
|
typedef std::shared_ptr< CRITERION > | PCriterion |
| | shared pointer to the criterion this step evaluates candidates against
|
|
typedef std::shared_ptr< SUBSET > | PSubset |
| | shared pointer to a feature subset
|
|
typedef std::shared_ptr< Result_Tracker< RETURNTYPE, SUBSET > > | PResultTracker |
| | shared pointer to the result tracker enabled via enable_result_tracking()
|
|
| | Sequential_Step_Ensemble (const PEnsembleCriteria ensemble, PEvaluatorEngine engine=PEvaluatorEngine()) |
| | Constructs the ensemble step over the given member criteria.
|
| bool | evaluate_candidates (RETURNTYPE &result, const PSubset sub, const PCriterion crit, const DIMTYPE _generalization_level=1, std::ostream &os=std::cout) override |
| | chooses among subsets offered by sub->get*CandidateSubset()
|
| virtual std::ostream & | print (std::ostream &os) const override |
| | Writes a human-readable identification of the step, incl. the engine's thread count (if threaded) and any attached result tracker.
|
|
void | enable_result_tracking (PResultTracker tracker) |
| | assigns a result tracker to this step, i.e., enables logging of all evaluated candidate subsets for future reuse (re-evaluation, etc.)
|
|
void | disable_result_tracking () |
| | detaches any result tracker (result_tracker_active() then returns false)
|
|
bool | result_tracker_active () const |
| | true if a result tracker was assigned via enable_result_tracking() and not since disabled
|
|
void | set_output_detail (OutputDetail detail) |
| | sets the amount of information that is logged to output stream throughout the course of search
|
|
OutputDetail | get_output_detail () const |
| | the currently configured output detail level
|
|
bool | output_normal () const |
| | true unless output detail is SILENT
|
|
bool | output_detailed () const |
| | true only at the DETAILED output level
|
template<class RETURNTYPE, typename DIMTYPE, class SUBSET, class CRITERION>
class FST::Sequential_Step_Ensemble< RETURNTYPE, DIMTYPE, SUBSET, CRITERION >
Implements voting ensemble selection step in sequential search type of methods to possibly improve robustness and stability of feature selection result.
Criteria ensembles may improve generalization and stability properties of the selected feature subset, see "P. Somol, J. Grim, and P. Pudil. Criteria Ensembles in Feature Selection. In Proc. MCS, LNCS 5519, pages 304–313. Springer, 2009." The idea is to reduce possible over-training, i.e., excessive result adjustment to particular criterion properties. By employing more different criteria the result is likely to be more robust in different contexts. Criteria ensembles as implemented here are based on voting about feature preferences. In sequential algorithm step, feature candidates are ordered separately according to each considered criterion. The various orderings are then joined (the position indices of a feature are summed over the criteria, which ranks the features the same way as averaging them would) to produce the final feature ordering. The best feature is then selected for addition to the current working subset. Note that this mechanism allows to use completely unrelated criteria, as the various criterion values are never combined - the only information that is combined is position index in ordered feature lists. This is advantageous as it enables combinations of filter and wrapper criteria (that yield values from different intervals) etc. Note, however, that the value obtained as result of ensemble evaluation is not usable for assessing the whole feature subset - it can be used only within the selection step to identify one feature (can be extended to feature c-tuple) for next inclusion/removal. For this reason it is also necessary to employ one single criterion to be used by selection algorithm for evaluating current subsets (and thus directing next search steps). This single criterion is used in the same way as in other FST4 Sequential_Step implementations, i.e. it must be passed in evaluate_candidates call. The criteria that form the ensemble are to be passed to Sequential_Step_Ensemble constructor.
- Note
- Single feature ordering implementation only. Support for generalized search (evaluation of candidate c-tuples instead of single features) may be implemented in future, but so far is not: evaluate_candidates() THROWS fst_error for any generalization level other than 1.
-
Like Sequential_Step_Straight this class serves both the sequential and the threaded execution model: the per-candidate evaluations of each ensemble member run through the injected Candidate_Evaluator, one batch per member criterion (default: sequential in-line evaluation; inject Candidate_Evaluator_Threaded for thread-pooled batches). The engine is typed on the abstract Criterion because that is how the ensemble members are held. Results are identical to sequential for any thread count: per-result callbacks fire in candidate order on the master, so the per-member ordered lists — and therefore the vote combination — come out the same whichever engine runs the batches (member criteria are deterministic and stateless across evaluate() calls, so evaluating member-by-member instead of candidate-by-candidate yields the same values).
-
One instance keeps a single set of iteration cursors and scratch lists, so a Sequential_Step_Ensemble object must not be used by two searches at the same time. Give each concurrent search its own instance.
template<class RETURNTYPE, typename DIMTYPE, class SUBSET, class CRITERION>
Builds, for each ensemble member, the ordered (best-first) list of candidate subsets in _lists, and seeds _final with one zero-valued entry per candidate feature.
Two passes: first the master enumerates sub's candidate subsets once (single-feature add/remove, i.e. generalization level 1) to register every candidate's temporary feature in _final and count the candidates. Then, for each ensemble member in turn, the candidates are re-enumerated and evaluated as one batch through _engine; the per-result callback performs a descending-value sorted insertion into that member's list in _lists, so the list is ordered from the member's most to least preferred candidate regardless of evaluation/callback order (results fire on the master in candidate order for any thread count).
- Parameters
-
| sub | the subset whose candidate subsets are ordered |
- Returns
- false if no candidate subsets exist, or if candidate enumeration or any member's evaluation fails