-
Notifications
You must be signed in to change notification settings - Fork 57
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Metrics #214
Labels
Comments
Morwenn
added a commit
that referenced
this issue
May 6, 2023
Morwenn
added a commit
that referenced
this issue
May 6, 2023
Morwenn
added a commit
that referenced
this issue
May 19, 2023
Morwenn
added a commit
that referenced
this issue
May 19, 2023
Morwenn
added a commit
that referenced
this issue
Jul 2, 2023
Morwenn
added a commit
that referenced
this issue
Jul 2, 2023
Morwenn
added a commit
that referenced
this issue
Aug 6, 2023
Morwenn
added a commit
that referenced
this issue
Dec 31, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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
The text was updated successfully, but these errors were encountered: