David Widmann

`==` is not guaranteed to return a `Bool` in general, in contrast to `===`. Eg it can return `missing`. But I've never seen that it would return a `Vector{Bool}`.

This seems to be caused by some weird behaviour of PyCall (possibly a bug?): ```julia julia> using PyCall julia> x = rand(3); julia> PyObject(x) == PyObject(x) 3-element Vector{Bool}: 1 1...

I opened an issue in the PyCall repo.

The problem seems to be `maximum(abs.(u))` in https://github.com/SciML/DiffEqBase.jl/blob/2daa81bfeb3df95c43469b96c058877a9cc240da/src/common_defaults.jl#L22. Maybe one should use `ODE_DEFAULT_NORM` or better the norm used by the integrator (which would have to be provided when calling `progress_message`)?...

I agree. Just noticed this inconsistency, and couldn't think of a simple way to fix the ambiguities apart from changing the way we handle `p`.

I'm wondering, couldn't we just define `recursivecopy!` as a regular function by just looping over the fields? Intuitively it shouldn't affect the performance too drastically but maybe I'm wrong. One...

Wouldn't it help if we add a function barrier and replace the `if` branches with a function call?

A bit unfortunate that Setfield does not support updating multiple fields at a time (https://github.com/jw3126/Setfield.jl/issues/62 mentions Kaleido.jl but it seems it only provides batch lenses but no equivalent to `@set!`)....

At least there are no explicitly marked stiff problems.... But http://scholarpedia.org/article/Stiff_delay_equations contains some stiff DDE problems, and even mentions a neutral problem from Enright and Hayashi. However, to me it...

Some test problems for RADAR5 are available on Hairer's site. Would be interesting to compare DelayDiffEq with RADAR5, but this would require both a Julia interface to RADAR5 (see https://github.com/luchr/ODEInterface.jl/issues/6)...