Closed sanjayankur31 closed 9 years ago
If the checker is used to break a run it should be initialized between the upper and lower break point. Otherwise a certain fraction of simulations will break due to noise even though their average firing rate is within the bounds. The rate estimate only becomes accurate after 3-5x the time constant of the RateChecker.
On 06/11/2015 08:57 AM, Ankur Sinha wrote:
Changes the rate checker initialisation and logic just a bit. The current version initialises the rate checker to (popmax + popmin)/2 which is very misleading - I was under the impression that my simulation had some firing right from the beginning, when it didn't actually have any activity at all.
The change initialises the checker to the minimum value You can view, comment on, or merge this pull request online at:
https://github.com/fzenke/auryn/pull/17
-- Commit Summary --
- Minor rate checker initialisation fix.
-- File Changes --
M src/RateChecker.cpp (4)
-- Patch Links --
https://github.com/fzenke/auryn/pull/17.patch https://github.com/fzenke/auryn/pull/17.diff
Reply to this email directly or view it on GitHub: https://github.com/fzenke/auryn/pull/17
Hrm, then maybe this should be mentioned somewhere and people suggested to first run a zero input phase in the simulation to get the checker to the required state. For simulations where the starting state itself is important, the checker giving wrong values is really misleading. I spent 3 days investigating where my neurons were getting input from :(
I am sorry this caused you that much trouble. I will add necessary documentation to clarify this point and add Checkers to the loading and saving mechanism of the System class to avoid this behavior when the network state is loaded.
Finally, I will add a set_rate(r) function to RateChecker so the rate estimate can be manually initialized to a sensible value.
I hope that helps.
Best,
Friedemann
On 06/11/2015 09:19 AM, Ankur Sinha wrote:
Hrm, then maybe this should be mentioned somewhere and people suggested to first run a zero input phase in the simulation to get the checker to the required state. For simulations where the starting state itself is important, the checker giving wrong values is really misleading. I spent 3 days investigating where my neurons were getting input from :(
— Reply to this email directly or view it on GitHub https://github.com/fzenke/auryn/pull/17#issuecomment-111191417.
That works too. Thanks.
Heya, since using the RateCheckers estimate for the progress bar was quite ugly, I changed this entirely now now in the latest commit 87aa631f1c15554c45852c852909042f423cbb9a in the develop branch. the System class now computes it's own online rate average. This one starts at zero upon init and is kept separately from the checkers.
Changes the rate checker initialisation and logic just a bit. The current version initialises the rate checker to (popmax + popmin)/2 which is very misleading - I was under the impression that my simulation had some firing right from the beginning, when it didn't actually have any activity at all.
The change initialises the checker to the minimum value