llnl / llnl/thicket

Use MultiIndex for ExtraP Functions

Open
#15 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

area-extrap priority-normal type-feature
Dominant language
JavaScript
Stars
18
Forks
10
PR merge metrics
No merged PRs in 30d

Description

The `componentize_statsframe` and `_add_extrap_statistics` extrap model functions both add a lot of columns to the statsframe.

**Statsframe**
| avg#inclusive#sum#time.duration_extrap-model | avg#inclusive#sum#time.duration_RSS_extrap-model | avg#inclusive#sum#time.duration_rRSS_extrap-model | ... |
| ------ | ------ | ------ | ------|
| cell | cell | cell | cell |
| cell | cell | cell | cell |

Currently, we are appending strings to the column name to distinguish them between each other. This becomes very messy fast and is not user friendly. I propose pulling out the common strings between the columns, like `avg#inclusive#sum#time.duration`, into a higher-level column index, and let the different strings distinguish each column, like `model`, `RSS`, `rRSS`.

And what if our statsframe already had other statistics and/or models in it? Our problem would only become worse. So I believe we can leverage multi-indexing to help us organize the statsframe.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reading the componentize_statsframe and _add_extrap_statistics functions to understand how they currently construct statsframe column names. The work is done when extrapolated statistics use organized multi-level columns that remain usable alongside existing statistics and models, rather than appending all distinctions into strings.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
data
Issue type
Refactor
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.