Ivan Borisov

In draft the idea 2. is: ``` using OnlineStats ... reduction = function(u,batch,I) if I == 1:1 num_t = length(batch[1].t) stats = [ Series(batch[1][i,:], OnlineStats.EqualWeight(), MV(num_t, Mean()), MV(num_t, Variance()), MV(num_t,...

My current draft wrapper for `reduction` takes dict of stats to be updated each iteration(`batch_size=1`), initializes `OnlineStats.Series` at `I==1:1` and updates the stats with each new `batch`: ``` function parameterized_reduction(task_stats::Array{Dict{String,V}...

I see, thanks

Then a simple workaround is to place `SavingCallback` after the `DiscreteCallback` and add something like `tstops-1e-6`/`tstops+1e-6` to `saveat` of the `SavingCallback`

I have the following code to use `Saving Callback` together with `ContinuousCallback`. The example is simple but it illustrates the issue I still haven't solved. The output order of timepoints...

And the output `out` is ``` SavedValues{tType=Float64, savevalType=Array{Float64,1}} t: [0.0, 12.0, 12.0, 10.0, 20.0, 30.0, 40.0, 50.0, 60.0, 70.0, 80.0, 90.0, 100.0] saveval: Array{Float64,1}[[10.0, 0.0, 0.01, 0.11], [8.8692, 1.1308, 0.01,...

Interesting... Rewriting `affect!` this way seems to have solved the issue: ``` function affect!(integrator) scb.affect!(integrator, true) u0 = integrator.sol.prob.u0 A__, B__ = integrator.u A__, B__ = u0 integrator.u .= A__,...

Back to this issue. My current approach to handle `SavingCallback` together with `ContinuousCallbacks` was to add the following lines to `affect!(integrator)` function like: ``` function affect!(integrator) # check if there...

Well, I am still thinking of a good way to handle `SavingCallback` interaction with other callbacks. The workaround I am using is to trigger saving from the `affect!` function of...

Gradient-based optimizers in general should be more efficient than derivative-free. You can use this gradient in `get_interval (... ; loss_grad)` function with one of the gradient-based local optimizers `local_alg`. I...