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

Ralf Gommers ralf.gommers@gmail....
Tue Jul 23 16:47:13 CDT 2013

On Tue, Jul 23, 2013 at 6:05 PM, Juan Luis Cano <juanlu001@gmail.com> wrote:

>  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>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.

The setter methods can use the private attributes to get around that, for
example num.setter updates self._den and not self.den.

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.

Not really, for the same reason. Assign to self._num and self._den.

> 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.

Should also work, but will likely be more complicated.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/scipy-dev/attachments/20130723/2ccaad3a/attachment.html 

More information about the SciPy-Dev mailing list