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