Skip to content

Design of algorithm configuration #131

@rrahn

Description

@rrahn

Summarizes the designs for the algorithm configuration.

See: https://github.com/orgs/seqan/projects/4#card-31347419 for recent discussions and open todos.
Here is the gist to the final design for dynamic and static config elements: https://gist.github.com/rrahn/16f2113015d39b55f5d89e0265f61f1c

Description

The configuration elements for the algorithms need to be unified in the naming and usability. A dynamic mode should be added for configurations that can hold alternatives, which are mutual exclusive. For this we want to establish rules for extending existing and designing new configurations.

Resolution

The design decisions are summarised in the following google sheet and will be transferred to the wiki.

Terms

  • configuration element: A single entity representing a specific property/feature of the underlying algorithm. It can be combined with other configuration elements from a different configuration group.
  • configuration group: A group of configuration elements, which are mutual exclusive.
  • configuration group selector: A dynamic configuration element representing the choice of a configuration group which can be modified at runtime.

Group selector details

  • use internally std::variant
  • befriend algorithm configurator
  • variant member is called selection and is private
  • config element itself offers assignment and construction
  • can always be default constructed and is valueless in this state (only the algorithm decides which default to use or wether to throw an exception for an invalid configuration).
class my_config
{
public:

    my_config() = default;
  
    template <typename option_t>
    my_config(option_t option) = selection{std::move(option)}
    {}

    template <typename option_t>
    my_config & operator=(option_t option) 
    { 
        selection = option;
        return *this;
    }

private:
     friend my_algorithm_configurator;  // access to selection member

      std::variant<A, B, C> selection{};
};

Naming of tags

  • some configuration elements only represent a tag
  • we use an constexpr inline variable to avoid explicit construction of that type
  • to call seqan3::get interface on the configuration we need a proper type name. This type shall be called name_of_variable + _tag, e.g.: inline constexpr vectorised_tag vectorised{};
  • the _tag class definition is in the same namespace as the corresponding variable

Naming of members for some configuration elements

  • seqan3::sarch_cfg::parallel.thread_count
  • seqan3::search_cfg::max_error_{insertion|deletion|substitution|total}.error
  • seqan3::search_cfg::hit_strata.stratum
  • seqan3::align_cfg::scoring_scheme.scheme
  • seqan3::align_cfg::min_score.score
  • seqan3::align_cfg::parallel.thread_count

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions