On 07/23/2013 11:47 PM, Ralf Gommers wrote:
On Tue, Jul 23, 2013 at 6:05 PM, Juan Luis Cano <juanlu001@gmail.com <mailto: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 <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.
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.
Thank you very much for your advice! I implemented these ideas in this pull request: https://github.com/scipy/scipy/pull/2655 I hope we can follow the discussion there and improve the code. Regards Juan Luis Cano