Document executed error norms in BackendHistory
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 1/5
- Estimated time
- Under an hour
- Newbie friendliness
- 86/100
- Issue type
- Documentation
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- python
- Domain
- backend, documentation
Research direction
Read src/solprop/backends/protocol.py at the linked revision and compare BackendHistory.error_norm with _march_to and _record in src/solprop/backends/driver.py. Update the attribute documentation to describe the executed trial norm and keep the equivalent controller history distinct. Done when the public record documentation matches the driver's contract and documentation checks pass, with no arithmetic or defaults changed.
Written by the indexing model from the issue text.
Description
What happens
BackendHistory.error_norm is documented as the error rescaled to the controller's unclipped proposal. The actual Runge–Kutta march records the executed trial norm. Only the controller's private accepted-norm history receives the equivalent proposal norm.
Why it matters
A backend implementing the session contract from the public record documentation could report different error histories at clipped or stretched landings even while making the correct numerical decisions.
Reproduction
Read, not a new numerical run: compare BackendHistory at ba7bee7a with _march_to and _record in the reference driver. _march_to computes equivalent, passes the original norm to _record, and appends equivalent to controller history. _record explicitly documents this executed-norm contract.
Context
Found during the independent Julia-owned session implementation in #611, tracking #608. Related session work is #607.
To do
- Correct the
BackendHistory.error_normattribute documentation to describe the executed norm. - Keep the separate equivalent controller history explicit and preserve numerical behavior.
Done when
The public record documentation agrees with the existing driver's contract and documentation checks pass. No arithmetic or defaults change.
- Dominant language
- Python
- Stars
- 3
- Forks
- 3
- Avg merge
- 8h 28m
- Merged PRs (30d)
- 176
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from LupoLab/solprop
-
bug
Difficulty 1/5 1-3 hours Newbie friendliness 86/100
Maintainers usually reply within 1 day
-
documentation priority: low
Difficulty 1/5 Under an hour Newbie friendliness 90/100
Maintainers usually reply within 1 day
-
documentation priority: high
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
documentation good first issue priority: low
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
area: native priority: low testing
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 1 day
Similar issues
-
bug triage
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
mealie-recipes/mealie#9117 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 83/100
freelawproject/courtlistener#8406 ·
Maintainers usually reply within 2 days
-
good first issue help wanted level 1 wocs
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
GianlucaBave/murmury#49 ·
Maintainers usually reply within 1 day
-
regression skipped skipped_bmg
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
intel/torch-xpu-ops#6142 · 1 comment ·
Maintainers usually reply within 2 days
-
good first issue help wanted python up-for-grabs
Difficulty 1/5 Under an hour Newbie friendliness 85/100
andrewsiah/agentswarm-data-tasks#122 ·
Maintainers usually reply within 1 day