[SciPy-Dev] Proposal: calling signal.lti object returns transfer function value
Tue Jul 23 16:47:13 CDT 2013
On Tue, Jul 23, 2013 at 6:05 PM, Juan Luis Cano <email@example.com> wrote:
> On 07/20/2013 05:54 PM, Ralf Gommers wrote:
> On Tue, Jul 16, 2013 at 5:28 PM, Juan Luis Cano <firstname.lastname@example.org>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):
> 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
Should also work, but will likely be more complicated.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the SciPy-Dev