Implement a robust tracking method based on Ogita-Aishima iteration - #23
Conversation
t-uda
changed the title
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
Codex Review: Here are some suggestions.
Reply with @codex fix comments to fix any unresolved comments.
About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you open a pull request for review, mark a draft as ready, or comment "@codex review". If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex fix this CI failure" or "@codex address that feedback".
| matrix_type="symmetric", | ||
| method="eigh", | ||
| correction_method="ogita_aishima", | ||
| solver_method="Euler", | ||
| solver_method="ogita_aishima", | ||
| correction_method=None, |
There was a problem hiding this comment.
[P1] Restore positional argument compatibility
The signature now lists solver_method before correction_method, whereas the previous release exposed the opposite order. Any existing call that passed these optional arguments positionally (e.g. eigenpairtrack(..., "matching", "RK45")) will now treat the correction value as the solver method and vice versa, typically resulting in invalid method names being forwarded to solve_ivp or correct_trajectory. Unless positional arguments are explicitly unsupported, this is a backwards‑incompatible change that will break working client code. Consider keeping the original parameter order or enforcing keyword‑only parameters to avoid silent API breakage.
Useful? React with 👍 / 👎.
1 participant
ogita-aishimaas a default option.notebooks/large_matrix_tracking_demo.ipynbto useogita-aishima.