Currently we've got measures of presortedness to analyze the collections to sort, but no module to analyze how sorters perform except for counting_adapter. Which is actually a shame since I am the first one to use such metrics when I need to show how much algorithms have improved in release notes. Historically I've used the following metrics to analyze algorithms:
Total running rime
Cycles per element
Number of comparisons
Number of projections
Number of moves
The simplest design would be for metrics to be sorter adapters, with a twist allowing them to combine their results into some kind of generic tuple with tag-based accessors (the original Ranges TS had such an extension to tuple, I could look into that, it would be yet another partial solution to #134). Said tuple should be printable, in which case it would display the information it gathered.
All metrics would go in a cppsort::metric namespace, and the individual files would go in cpp-sort/adapters/metrics, with or without a metrics.h file allowing to include them all.
To make metrics more usable, a combine_metrics utility could be introduced, allowing to write something along these lines:
Currently we've got measures of presortedness to analyze the collections to sort, but no module to analyze how sorters perform except for
counting_adapter
. Which is actually a shame since I am the first one to use such metrics when I need to show how much algorithms have improved in release notes. Historically I've used the following metrics to analyze algorithms:The simplest design would be for metrics to be sorter adapters, with a twist allowing them to combine their results into some kind of generic tuple with tag-based accessors (the original Ranges TS had such an extension to tuple, I could look into that, it would be yet another partial solution to #134). Said tuple should be printable, in which case it would display the information it gathered.
All metrics would go in a
cppsort::metric
namespace, and the individual files would go incpp-sort/adapters/metrics
, with or without ametrics.h
file allowing to include them all.To make metrics more usable, a
combine_metrics
utility could be introduced, allowing to write something along these lines:I believe that those metrics can mostly be implemented in a non-intrusive way, though the moves counter might be trickier to get right.
Roadmap for a first release - the helper types can be simple at first and completed later as needed:
metric<T, Tag>
type, basically a tagged value wrappermetrics<Metrics...>
type, mostly a tuple ofmetric
metric
andmetrics
combine_metrics
comparisons
projections
running_time