patrick-kidger / patrick-kidger/diffrax

Making subsaveat consider previous saves and not just the current one

Open
#472 4 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

question
Dominant language
Python
Stars
2.1k
Forks
189
Avg merge
3d 18h
Merged PRs (30d)
1

Description

When using Saveat we have the option to call a "fn" defined in the doc as

fn: A function fn(t, y, args) which specifies what to save into sol.ys when using t0, t1, ts or steps. Defaults to fn(t, y, args) -> y, so that the evolving solution is saved. For example this can be useful to save only statistics of your solution, so as to reduce memory usage.

but why not changing it to be something like fn(save_state, t, y, args) in _integrate.py where it is called line 218 under

def _save(
    t: FloatScalarLike,
    y: PyTree[Array],
    args: PyTree,
    fn: Callable,
    save_state: SaveState,
) -> SaveState:
    ts = save_state.ts
    ys = save_state.ys
    save_index = save_state.save_index

    ts = ts.at[save_index].set(t)
    ys = jtu.tree_map(lambda ys_, y_: ys_.at[save_index].set(y_), ys, fn(t, y, args))
    save_index = save_index + 1

    return eqx.tree_at(
        lambda s: [s.ts, s.ys, s.save_index], save_state, [ts, ys, save_index]
    )

we could then save a function that depends not only on the last state but also on the previous ones... (which can be useful in my case and I believe is more general than current version "for free")
we ought to also modify the default function for fn in _saveat.py

def save_y(t, y, args):
    return y

to

def save_y(save_state, t, y, args):
    return y

and I think it should be okay ?
Of course I could do it myself and work with such a diffrax but i'm working on a library which is dependent on a library which itself is dependent on diffrax, so I'm interested for it to be in the "real" diffrax, so that my library keeps up with the version of the library above me haha

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 with _integrate.py at _save and _saveat.py at save_y, then trace how SaveState and Saveat are passed through saving. Check the documented fn signature and existing save behavior before changing the API. Done means a save function can use prior saved values while the default save_y behavior remains unchanged.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
backend
Issue type
Feature
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.