Converted from SourceForge issue 3427208, submitted by ceball
Submit Date: 2011-10-22 12:01 GMT
One example
---------- Forwarded message ----------
From: Bilal Khan s0681194@sms\.ed\.ac\.uk
Date: Sat, May 7, 2011 at 21:15
Subject: Re: Topographica-cvs Digest, Vol 60, Issue 7
To: jbednar@inf.ed.ac.uk
Cc: Chris Ball ceball@gmail\.com
...
On 7 May 2011, at 11:25, James A. Bednar wrote:
From: Bilal Khan
Date: May 6 15:08:01 2011 +0100
On 2 May 2011, at 22:27, Chris Ball wrote:
...
>> def _setParams(self, **params):
>> - """
>> - For subclasses: to specify the values of parameters on this,
>> - the parent class, subclasses might first need access to their
>> - own parameter values. Having the initialization in this separate
>> - method allows subclasses to make parameter changes after their
> I don't know any of the details here, but I've noticed this (and
> things like it) before. It seems like something that should
> either not be happening, or that indicates a limitation of
> parameterized objects, and so should be addressed more generally
> :)
It's a huge limitation .. almost all the auditory methods require
access to parameters that aren't available until late on in model
initialisation. For example Spectrograms require horizontal sheet
dimensions, how else will they know how much temporal history to
keep? We could presumably use a param but thats a waste of a param,
and then what if the param doesn't match the sheet dimensions?
Everything that inherits from Spectrogram also inherits this issue.
Likewise TimeSeries needs to be updatable by its subclasses after
it's been initialised, AudioFolder will keep updating the time
series param with the next file from the specified folder once we
reach the end of the current file. Any microphone class would be a
subclass on TimeSeries too and that would constantly need to update
its params after the usual init call.
The only solution i've come up with thus far is to set a special
var that identifies the first call and sets/resets all the
params on that call. If we wanted to do this more generally a
decorator class for the param mother class would be an option. I
half wrote one before i got bored and realised i didn't want to
take responsibility for it.
Hmm... I can see a bit of what the problem is, but not enough right
now to suggest a better solution.
It's actually worse than that .. at least there are viable workarounds for the problems above, which is to say the parameters needed to correctly initialise those methods are eventually made available, albeit later than we would like.
The topotopic map measurement code is another story, its parameters are totally hard wired since the map measurement methods have no access to sheet dimensions whatsoever.
Converted from SourceForge issue 3427208, submitted by ceball Submit Date: 2011-10-22 12:01 GMT
One example
---------- Forwarded message ---------- From: Bilal Khan s0681194@sms\.ed\.ac\.uk Date: Sat, May 7, 2011 at 21:15 Subject: Re: Topographica-cvs Digest, Vol 60, Issue 7 To: jbednar@inf.ed.ac.uk Cc: Chris Ball ceball@gmail\.com ... On 7 May 2011, at 11:25, James A. Bednar wrote:
It's actually worse than that .. at least there are viable workarounds for the problems above, which is to say the parameters needed to correctly initialise those methods are eventually made available, albeit later than we would like.
The topotopic map measurement code is another story, its parameters are totally hard wired since the map measurement methods have no access to sheet dimensions whatsoever.