The evalfr function in the lti module expects a complex number and evaluates the system at that complex frequency. The method sys._evalfr, on the other hand, where sys is a transfer function or state space system, expects a real argument and multiplies it by j before evaluating the frequency response.
Is this dichotomy intentional?
- matlab's
evalfr function expects a complex number, which seems like a more general-purpose solution. sys.freqresp expects real-valued omega arguments, making it perhaps a better interface for users
- also, right now, only
sys._evalfr correctly performs the z-plane transformation for discrete-time systems.