[SciPy-Dev] Proposal: calling signal.lti object returns transfer function value
Juan Luis Cano
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 <email@example.com
> <mailto: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:
@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...
More information about the SciPy-Dev