MatthewFlamm

The current proposal only passes the `OdeSolver` object. I considered that some of the information from `solve_ivp` might be useful too, for example the history of the solution, i.e. the...

Not using `t_eval` for the test included in this PR, the intermediate `t` inside `solve_ivp` is a list of mixed types: ```py [0.0, np.float64(9.995002448825549e-05), np.float64(0.0010994502693708105), ..., np.float64(1.9592863089832577), 2.0] ``` and...

Less lazy: the intermediate type and shape of t and y depend on whether `t_eval` is used. `t` is like ```py [array([0]), array([1]), array([2])] ``` `y` is like ```py [array([[0.],...

Some sketch proposals. Some of these would be larger proposals, but out here for completeness: 1) An `IntermediateOdeResult` which mirrors `OdeResult` that inherits from `_RichResult`. It is formed like (this...

> In minimize, callback functions can stop the the algorithm gracefully by raising a StopIteration exception. Thanks! Let's use the precedent here. > I think that's fine as long as...

> > should the callback only be triggered at those times rather than after every step? > > I don't think so. I haven't looked at the implementation, but is...

> > but wanted to raise it as it would be a breaking change if someone wants it later. > > What would be "breaking"? You mean because given the...

> OK, I think we can just say that we won't call the callback at the `t_eval` points. I do think we should plan on having a callback called at...

> I suppose the difference with your scheme is just that the user's callback might have to execute multiple branches (one for the time step, and one for each event...

I started https://discuss.scientific-python.org/t/design-of-callback-for-scipy-integrate-solve-ivp/1672. I tried to capture the options discussed here with the upon-event and upon-event-type distinction as well as the single callback vs. separate callback distinction.