Add target_coverage parameter to logarithmic_windows...

[jonscheunemann]

and corresponding tests.

Added to hold the ratio of measurement steps to actual steps for increasing batchsizes almost constant

[Copilot]

Pull request overview

This PR adds a target_coverage parameter to perspic.logger.logarithmic_windows() to derive base_window from max_steps, aiming to keep the ratio of measurement steps to training steps roughly constant across runs where max_steps varies (e.g., batch-size sweeps).

Changes:

• Added target_coverage: Optional[float] to logarithmic_windows() and documented its intended usage/behavior.
• Implemented base_window derivation from target_coverage, max_steps, and the computed number of log points.
• Added a new unit test suite covering target_coverage behavior and its interaction with adaptive_scale.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
perspic/logger.py	Adds the target_coverage parameter, documents it, and derives base_window from it when provided.
tests/unit/test_logger.py	Introduces new unit tests validating target_coverage behavior and coverage constancy across a batch-size sweep.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[KonstiNik]

If I understand correctly, the idea here is that for different batch sizes / num-steps you get the same coverage in measurements – so sth like 10% of all the steps are measured.

This is a nice idea, and I'd like you to take this into account:

Having a window_size=50 at a given batch size will give you a certain accuracy for the LNP components (See Fig. 6 in our paper). Increasing the batch size will make the computation more accurate at each step (I think falling with $\sim 1/\sqrt{\text{batch size}}$). I believe what's important here is that measurements of runs with different batch sizes have the same statistical error. I think to achieve that, we want to match the number of overall tokens we take into account in the respective measurement window.

How does that compare to what's currently implemented?