Re: [Amygdala-development] New user feedback, bug corrections in patch!

[Nicolas B. <nic...@fr...>]

Le Lundi 30 Janvier 2006 09:39, R=FCdiger Koch a =E9crit=A0:
> I can think about 2 ways to work around using "typedef unsigned long
> long AmTimeInt":
>
> 1. We simply let the simTime run over. That requires to use only
> operations on time variables that produce correct results when time
> just ran over. The common operation dt =3D t2 - t1 is safe as long as
> AmTimeInt is unsigned, pretty much everything else requires a case
> differentiation.
>
> 2. Once simTime exceeds a certain value (say, 4 Billion) we subtract
> one Billion from all time variables

Another consideration is:

When you post a spike, currently this is done in absolute time. Why not=20
changing this to post a spike in relative time frow "now", whatever that is=
?=20
This is more logical, since neurons do not have a built-in clock, they just=
=20
maintain their own discharge time.
In the network.cpp code, when pushing the newly scheduled spike in the even=
t=20
list, maintain "now" as an additional field in the SpikeInputRequest=20
structure, or convert to absolute time internally, whichever is more=20
convenient.

You'd still have to use one of the 2 tricks you mentionned (either wrap-aro=
und=20
of subtracting big value) but this time, only the network has the notion of=
=20
absolute time, so this is less opportunity for bugs. If you need the absolu=
te=20
time externally for any reason, provide Network::GetAbsoluteTime (for examp=
le=20
returning a structure, with second/usec, exactly what the time POSIX=20
functions do).

Now, I'm new to Amygdala, so don't have your background to analyze if this =
is=20
really a good idea or not.


> For both workarounds we'd increment an epoch variable.

The notion of epoch may be confusing to users. If all code refering to=20
absolute time is isolated, there is no need for it.


> Both workarounds are excellent hiding places for bugs, of course. Some
> bugs of that type are probably already present. So what we can do is:
>
> 1. Initialize simTime to one second under the maximum value to make
> sure that there is at least one overrun for every decent simulation so
> bugs are forced to come out of hiding. That's how Linux is handling
> potential jiffie overruns after 28 days.

BTW, another unrelated problem I had is that currently Amygdala initializes=
=20
the simulation at +1 timestep, but then checks for simtTime<maxTime in the=
=20
run loop. TimeStep() increments the simTime after processing, for the next=
=20
call.

This lead to a dissymetry, quite important in my case since the first and l=
ast=20
"epochs" were not having the same number of time steps.

I had to modify the code so:
=2D simulation time is initialized to 0.
=2D TimeStep() increases the current simtime before processing.
=2D the run loop checks for simTime<=3DmaxTime

Now each epoch is having exactly the same number of time steps.

Regards,
Nicolas