Climbing Ratings 4.0.0

Changes since 3.0.1:

Styles and style-pages

Support for ascent styles was added, which fits a "relative" climber rating for each style that can change over time, relative to a base style. For example, this can be used to model the difference between a climber's trad and sports rating. It could also be used to estimate the effect of different tick types on ascent success, on a per-climber basis.

The inputs to the estimation script have changed as a result; there is an additional style_page column in ascents.csv, and a completely new file style_pages.csv. The estimation script produces a new file style_page_ratings.csv with estimated ratings. The model has two additional hyperparameters: style prior variance (similar to the climber prior variance) and the style Wiener variance (similar to the existing Wiener variance for climbers).

To emulate the previous behaviour of no styles, set the style_page field to -1 for all ascents, and create style_pages.csv with just the header row (or make the equivalent calls via the Python API).

Known issues with styles:

• The post-estimation analysis functions have not been updated to take styles into account.
• Experimentation to measure the performance of this more complex model has been quite limited.

Python library API

The public interface to the Python library (through climbing_ratings.WholeHistoryRating) has changed. Rather than passing in lists, pass in AscentsTable and PagesTable types. The computation of "slices" is now encapsulated within the climbing_ratings package, too, so it's sufficient to pass in the normalized tables. The page ratings are now encapsulated in the PageRatingsTable type.

Extended Precision Calculations

Internally, calculations involving the exponentiated Bradley-Terry terms now use long double instead of double. This improves numerical stability, especially with larger prior variances and more extreme ratings. This change should not break anything (other than changing estimates). However, it makes the estimation slower by 10-25%, and can be expected to consume 25% more memory.

Timestamps

Absolute timestamps can be passed to the estimation library, rather than the data preparation logic calculating relative timestamps. This makes it easier to interpret the CSV files without the original data.

theCrag Data files

The API calls and resulting JSON output files have changed structure. The code that parses the JSON is not backwards-compatible with JSON files downloaded with previous versions.

Pitches and styles are extracted from the JSON. Pitches are extracted from logbook exports using a heuristic.

RDS files

To make backwards-compatibility easier for future releases, the data preparation scripts now write RDS files containing the raw and normalized tables. This also has the benefit of allowing post-estimation analysis to merge the estimation results and normalized tables without having to reprocess the original ascents data (which can be very slow for JSON).