DOC:signal: Fix typo in TransferFunction

[kasparthommen]

Reference issue

Closes #17047

What does this implement/fix?

Fixes a few documentation erros.

[tupui]

Thanks @kasparthommen for the PR. I might be wrong but the equation seems to just refer to the parameter dt which states s. Seems to me that it's a clear case of mathematical correctness vs programming logic.

[kasparthommen]

Thanks @kasparthommen for the PR. I might be wrong but the equation seems to just refer to the parameter dt which states s. Seems to me that it's a clear case of mathematical correctness vs programming logic.

Hi @tupui , thanks for taking a look. I think you're wrong: continuous transfer functions operate on a complex variable s, whereas discrete transfer functions use the complex variable z. This has nothing to do with dt.

The 1st and 3rd case clearly use the wrong variable s on the LHS because the RHS (correctly) employs z. The 2nd case is different because both the LHS and RHS are wrong; they both use s even though the equation is a discrete transfer function.

(Note that there is an additional complication in the 2nd case as there is in fact a z variable on the righ-hand side, but it doesn't refer to the complex variable used for discrete transfer functions but to the array of zeros. Therefore, I have also renamed that RHS z to q which is standard practice.)

[tupui]

As I said, I am purely talking about the argument names, not the mathematical correctness. With your proposal, We would miss a definition of z whereas atm s is defined in the docstring.

[kasparthommen]

It is indeed mathematically incorrect to call a formula involving the variable z a function of s, or H(s). This error is being corrected by my PR.

Also, the s you are referring to in the docstring dt: ... Sampling time [s] has an entirely different meaning: it is simply the shorthand notation of "seconds", the physical unit of the optional parameter dt. Note here that dt is the docstring parameter, not s. The latter has no relationship with the s in H(s) whatsoever.

[ilayn]

It looks OK, thanks @kasparthommen. These are conventions anyways so we don't need to recite the control textbooks too much.