Re: [python-control-discuss] Implementation of lsim, step, initial, impulse

[Richard M. <mu...@cd...>]

Hi Eike.  Thanks for the comments.  I'm cc'ing the discussion list since it would be useful to get the perspective of others as well before making a final decision.  

I agree that the default behavior should be something that is well thought out and consistent.  Then the question is whether in cases where that conflicts with MATLAB, we provide any sort of support for the MATLAB convention.

-richard

On 18 Jun 2011, at 17:24 , Eike Welk wrote:

> Hello Richard!
> 
> On Saturday 18.06.2011 03:02:07 you wrote:
>> Eike,
>> 
>> I'm working on integrating some of the functionality that you contributed
>> to the python-control package.  Your new convention for simulation inputs
>> and outputs has a lot of nice features, but it does "break" current code
>> (eg, try running examples/pvtol-nested.py).  In addition, it is not
>> compatible with the way MATLAB or scipy.signal does things, which could be
>> confusing.
> 
> You should devise a convention, and I'll convert my code to this convention.
> 
> A good alternative IMHO would be to transpose all matrices of my convention. 
> This is compatible to Matlab's ``lsim`` and ``scipy.integrate.odeint``. Also 
> Matplotlib is OK with it, if it's done right.
> 
> I personally don't like to use matrices as return values for ``lsim``, because 
> of their confusing behavior. Also you usually don't do linear algebra with a 
> time series of values. On the other hand, the users (who are probably not 
> experienced programmers) might be confused if they have to consider different 
> data types (matrices and arrays). 
> 
> But make sure, that simple things are simple. For example this should work:
> 
>>>> t, y = step(sys)
>>>> plot(t, y)
> 
> For the compatibility of matrices with Matplotlib see:
> 
> #This works:
> In [7]: t1 = array([1, 2, 3])
> 
> In [8]: t2 = matrix('1; 2; 3')
> 
> In [9]: y = matrix('1; 4; 9')
> 
> In [10]: plot(t1, y)
> Out[10]: [<matplotlib.lines.Line2D object at 0x26d3d90>]
> 
> In [11]: plot(t2, y)
> Out[11]: [<matplotlib.lines.Line2D object at 0x26de850>]
> 
> 
> #But this results in a ``ValueError``:
> In [12]: t3 = matrix('1, 2, 3')
> 
> In [13]: plot(t3, y)
> 
> 
>> 
>> As a general principle, I think that if a user imports control.matlab, they
>> should get as MATLAB like an environment as possible (since control.matlab
>> is the MATLAB emulation module in the package).  However, I see now reason
>> why we need to maintain MATLAB compatibility within the underlying library
>> itself, where we can do things in a more python-like way.  But breaking
>> the convention used by scipy.signal could get confusing...
> 
> Trying to emulate Matlab closely is IMHO unnecessary, and also impossible. You 
> will never get the elegance of Matlab, since the language is optimized for its 
> specific task. 
> 
> Especially: 
> * Python has no ``.*`` operator. 
> * Python functions don't know how many return values are requested.
> 
> I think the functions should have the same names as in Matlab, so that Matlab 
> users can quickly find the functionality that they need. The arguments need 
> only to be roughly equivalent. For details, the users should be educated to 
> type ``function_name?`` in IPython, or to look at the documentation website.
> 
> Instead of closely emulating Matlab you should strive for a consistent user 
> interface, and good integration with the rest of Numpy, Scipy and Matplotlib.
> 
>> 
>> Here is one possible fix:
>> 
> ...
> ...
>> Let me know what you think about this (others on the list as well).  If we
>> do decide to switch the way time series are represented from the current
>> version, we would have to update the version number to something like 0.5a
>> (instead of 0.4d) since we would be breaking existing code.
> 
> Just tell me how you think it would be best, and I'll port it to this form. A 
> library of incongruous  parts, is IMHO less useful than a parameter 
> convention, that I find somewhat impractical.
> 
> There don't seem to be many users currently, so breaking the interface should 
> be not very problematic.
> 
> I have an other patch, that converts big part of the module documentation to 
> proper Sphinx markup, so that you can soon put the generated documentation on 
> a server. Something which I find very important. 
> 
> 
> Yours,
> Eike.