Delay blocks do not belong to Blocks.Nonlinear

[casella]

The Blocks.Nonlinear package contain three time delay implementations: FixedDelay, PadeDelay, and VariableDelay.

As everybody knows, pure time delay y(t) = u(t - tau) is a linear operator, linear as linear can be, since obviously the superposition principle applies to it 100%. It is in principle infinite-dimensional, but that doesn't make it less linear. Also its Padé approximation is of course linear, as explicitly explained in the documentation.

I guess the only reason why these blocks belong to Blocks.Nonlinear is to mimick the Simulink Block library, where the delay block was put in the Nonlinear category 30 years ago for reasons I cannot fathom.

I don't think we need to worry too much looking the same as Simulink, at least as far as wrong features are concerned. We should rather worry about not calling Nonlinear something which is most definitely 100% linear.

I would propose to move those three blocks to Continuous, where they belong, now that we have a once-in-a-lifetime opportunity to do so with the conversion scripts. If there is consensus about this, I can open a proper PR with the code change ASAP.

Please note this can only be done in 4.0.0, not in a subsequent minor release.

[beutlich]

Since we won't touch upcoming MSL 4.0.0 to introduce any new conversion rules, we have to postpone the proposed changes until MSL 4.0.0 is released and branched to maint/4.0.x.

now that we have a once-in-a-lifetime opportunity to do so with the conversion scripts

Next opportunity already is for MSL v5.0.0 or v4.1.0 to be expected in spring 2021 (provided we decide on #3461, and if we claim that changes requiring conversion imply a new MAJOR revision).

[HansOlsson]

(Well, VariableDelay is non-linear in the delay argument.)
However, NonLinear is a bad name - especially as most non-linear blocks are in Math.

Since they all have internal states Continuous does seem like a better fit for the delays.
And the remaining ones in NonLinear are then limiters and deadzone, and we might be able to find a better name for them.

[casella]

Next opportunity already is for MSL v5.0.0 or v4.1.0 to be expected in spring 2021 (provided we decide on #3461, and if we claim that changes requiring conversion imply a new MAJOR revision).

Just as a clarification, according to SEMVER, a major revision is required if you change the API. In case we have a conversion script, would this change be considered as "not changing the API", so it could end up in 4.1.0?

[dietmarw]

No because the conversion script would change the user library so it can work with the new MAJOR version. It will no longer be able to work with the previous version. Conversion script is a one-off operation to the user library.

[MartinOtter]

I would propose to move those three blocks to Continuous, where they belong, now that we have a once-in-a-lifetime opportunity to do so with the conversion scripts. If there is consensus about this, I can open a proper PR with the code change ASAP.

Fine for me

[casella]

No because the conversion script would change the user library so it can work with the new MAJOR version. It will no longer be able to work with the previous version. Conversion script is a one-off operation to the user library.

I'm confused. @beutlich mentioned 4 days ago that this change could end up in 4.1.0, which is a MINOR version. Do I miss something?

[dietmarw]

He said " MSL v5.0.0 or v4.1.0" and it will depend what the exact nature of the change is.