Ricardo J. M=E9ndez wrote:
>On 11/22/05, Colin Green <cg...@ds...> wrote:
> =20
>
>>Yeh this is just wrong. Have made the change here. You probably also
>>noticed I often don't call clear right at the start, which is normally
>>Ok because the network was normally just built, but in the general case
>>it's an assumption and that's bad.
>> =20
>>
>
>I've noticed that in running an experiment, saving a population and
>then re-loading it to continue the experiment, networks that were
>previously optimal and had remained stable for a while tend to go out
>of whack, but I've never really chased the issue. I wonder if this
>lacking of an beginning initialization is what's throwing it off.
>
>Hmmm.... However, I'm always clearing the signals before even setting
>the first input signal, so that's probably not it.
> =20
>
I've chased up this issue in the past but it's one of those things that=20
you have to keep an eye on as it seems to creep back in occasionally. On=20
one occasion it was due to the casting between doubles and floats. The=20
default network class - FloatFastConcurrentNetwork - uses floats, but=20
the genome class uses doubles and the file formats [should] store the=20
full precision of a double. Thus if you are saving/loading genomes and=20
populations then there shouldn't be a problem, but if you saving a=20
network you might lose some precision. It's something to keep in mind=20
anyway, some problem domains are more sensitive to small changes in=20
connection weights than others. Also note sometimes if you have been=20
running a search for a long time with only small improvements in fitness=20
then these improvements can be represented by small weight changes.
> =20
>
>>Maybe if networks set a flag when
>>they are created (which resets on the first activation) we can check
>>this to determine if a full clear is really required, then we can call
>>clear at the top of all experiments, safe in the knowledge we won't be
>>doing an unnecessary clear.
>> =20
>>
>
>Certainly. Another option is having a network preference
>"InitialAutoClear" , which defauls to True, which checks said flag on
>call to "SetInputSignals" to see if an initial clearing is necessary.
> =20
>
Could do, but I prefer to leave it to the user to call clear if they=20
want a clear, it's simple and immediately obvious from the point of view=20
of a new coder. Also some experiments want clearing on, say, alternate=20
calls to SetInputs, in cases like that it's easier to just keep it=20
simple and trust that the coder of the experiment knows what they're=20
doing :)
C.
|
