[SciPy-Dev] Proposal: calling signal.lti object returns transfer function value

Juan Luis Cano juanlu001@gmail....
Tue Jul 23 11:05:12 CDT 2013


On 07/20/2013 05:54 PM, Ralf Gommers wrote:
>
>
>
> On Tue, Jul 16, 2013 at 5:28 PM, Juan Luis Cano <juanlu001@gmail.com 
> <mailto:juanlu001@gmail.com>> wrote:
>
>     BTW (and this is a side question), is there a reason the code of
>     signal.lti is full of `self.__dict__['X'] = Y` instead of `self.X
>     = Y`?
>
>
> It's very ugly but does have a function. Because of how 
> ``__setattr__`` is implemented you cannot just set self.num & related 
> attributes in ``__init__``. The alternative is to transform 
> num/den/zeros/poles/.... into properties with setter methods that keep 
> all properties in sync. A PR making that change would be welcome.

If I understood correctly, it would be something like this:

@property num(self):
     """Numerator"""
     return self._num

@num.setter num(self, value):
     self._num = value
     self.__dict__['zeros'], self.__dict__['poles'], self.dict__['gain'] 
= tf2zpk(self.num, self.den)
     self.__dict__['A'], self.__dict__['B'], self.dict__['C'], 
self.dict__['D'] = tf2ss(self.num, self.den)

then you really cannot get rid of `self.__dict__['X']` because if you 
use the `self.X` then the same circular problem would happen with the 
setters of the other properties. And on the other hand, when 
instantiating the object not all the properties are available (e.g.: you 
assign `num`, but cannot update zeros, poles and gain because `den` is 
not yet assigned) so a special case has to be included in the setter.

What about, instead of storing redundant information on the object, a 
"canonical" representation is used, for instance (A, B, C, D), and 
getters are created that compute (num, den) and (zeros, poles, gain)? 
Maybe one could even cache these properties so they would be computed 
only once anyway.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/scipy-dev/attachments/20130723/cc5dba27/attachment.html 


More information about the SciPy-Dev mailing list