NoiseProcess type hierarchy

[oameye]

To implement when which algorithm is compatible with which noise type we need to distinguish between them after creation. Would it be sensibele to make a type system on top of NoiseProcess? The CamelCase names seems already to suggest that we should think of them this way.

SciML/SciMLBase.jl#774

[ChrisRackauckas]

It would be fine to add one if you have a sensible breakdown you're interested in.

[oameye]

I was thinking of making every NoiseProcess their own subtype with the same fields as NoiseProcess. That way, e,g., WienerProcess <: NoiseProcess , is distinguishable from GeometricBrownianMotionProcess. Essentialy upgrading the object from a function to a struct. However, under the hood it is still just the NoiseProcess struct.

Alternatively, we can just add another field with the name of the process.

[ChrisRackauckas]

AbstractNoiseProcess, yes

[oameye]

I was trying some things out and came across the classic inheritance vs. composition dilemma. Initially, I envisioned an inheritance approach where WienerProcess would inherit all the fields of NoiseProcess. However, implementing inheritance in Julia would require adding a dependency or using an @inherit macro, as discussed here. I guess this is not really the Julian way.

The alternative is to use composition:

struct WienerProcess <: AbstractNoiseProcess
    process::NoiseProcess
end

With this approach, I would need to define functions like:

process(x::WienerProcess) = x.process
process(x::NoiseProcess) = x

This way, I can use process in any method that dispatches on AbstractNoiseProcess. Do you think this approach is preferable?

One drawback of using types is the additional need to define in-place versions, like WienerProcess!. Perhaps it might be simpler to add a field process::Symbol in NoiseProcess to store the process type information directly.

[ChrisRackauckas]

I think a composition approach could be nice. A basic noise process which then is composed with other things to extend.