Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ring buffer sigma and spikes-per-second on a per synapse-type basis #136

Open
alan-stokes opened this issue Aug 25, 2015 · 8 comments · May be fixed by #852 or #1386
Open

Ring buffer sigma and spikes-per-second on a per synapse-type basis #136

alan-stokes opened this issue Aug 25, 2015 · 8 comments · May be fixed by #852 or #1386
Assignees
Labels
Milestone

Comments

@alan-stokes
Copy link
Contributor

different synapse types have different statistics and separate ring-buffer shifts to scale them with, so ideally, you should also be able to specify ring buffer sigma and spikes-per-second separately for different synapse types.

linked to #132

@hopper333
Copy link
Contributor

The ring-buffer scaling is a function of connectivity and expected input firing rates in a particular network configuration, so pretty well independent of synapse type.

M


Michael Hopkins,
SpiNNaker project,
APT group, School of Computer Science,
University of Manchester,
Manchester M13 9PL
[email protected]:[email protected]

On 25 Aug 2015, at 10:11, Alan Stokes <[email protected]mailto:[email protected]> wrote:

different synapse types have different statistics and separate ring-buffer shifts to scale them with, so ideally, you should also be able to specify ring buffer sigma and spikes-per-second separately for different synapse types.

linked to #132#132


Reply to this email directly or view it on GitHubhttps://github.com//issues/136.

@rowleya
Copy link
Member

rowleya commented Aug 25, 2015

You can do the scaling per synapse type i.e. if you know the firing rate of all the populations exciting this population and a different firing rate for all the populations inhibiting this population, you can do two separate calculations. We already do the separate calculations but we use a firing rate and sigma value which is fixed over the entire simulation. If you know more about your network, the ability to change this per population and per synapse type could help you to get better overall results; how much is to be seen, but it isn’t too hard to enable this (Alan has already done it per-population, per synapse-type is a bit more fiddly but doable).

From: Michael Hopkins [mailto:[email protected]]
Sent: 25 August 2015 11:45
To: SpiNNakerManchester/sPyNNaker [email protected]
Subject: Re: [sPyNNaker] Ring buffer sigma and spikes-per-second on a per synapse-type basis (#136)

The ring-buffer scaling is a function of connectivity and expected input firing rates in a particular network configuration, so pretty well independent of synapse type.

M


Michael Hopkins,
SpiNNaker project,
APT group, School of Computer Science,
University of Manchester,
Manchester M13 9PL
[email protected]:[email protected]mailto:[email protected]%3cmailto:[email protected]

On 25 Aug 2015, at 10:11, Alan Stokes <[email protected]<mailto:[email protected]mailto:[email protected]%3cmailto:[email protected]>> wrote:

different synapse types have different statistics and separate ring-buffer shifts to scale them with, so ideally, you should also be able to specify ring buffer sigma and spikes-per-second separately for different synapse types.

linked to #132#132


Reply to this email directly or view it on GitHubhttps://github.com//issues/136.


Reply to this email directly or view it on GitHubhttps://github.com//issues/136#issuecomment-134552799.

@rowleya rowleya removed this from the December 2015 release milestone Sep 21, 2016
@alan-stokes alan-stokes added the incomplete_left_for_further_release Postponed past a release label Aug 3, 2017
@alan-stokes alan-stokes added this to the 5.0.0 milestone Aug 3, 2017
@dkfellows dkfellows removed the incomplete_left_for_further_release Postponed past a release label Sep 29, 2017
@dkfellows dkfellows modified the milestones: 5.0.0, 5.1.0 Aug 12, 2019
@dkfellows dkfellows modified the milestones: 5.1.0, 6.0.0 Nov 22, 2019
@Christian-B
Copy link
Member

Is this still valid?

@rowleya
Copy link
Member

rowleya commented Mar 22, 2021

I still don't think it is possible to do this. I don't know where it is relevant to do so.

@Christian-B Christian-B modified the milestones: 6.0.0, Bluesky Mar 22, 2021
@hopper333
Copy link
Contributor

hopper333 commented Mar 22, 2021 via email

@rowleya
Copy link
Member

rowleya commented Mar 22, 2021

We haven't completely moved to that yet, mainly due to issues with working out what the "atomic" weight will be! I think we will end up needing a combination of techniques e.g. maximum weight calculation, then minimum weight = max / 65536, and then also add in stochastic rounding to do things smaller than min weight. It will take a bit of effort to get these things done though!

@hopper333
Copy link
Contributor

hopper333 commented Mar 22, 2021 via email

@andrewgait
Copy link
Contributor

I would think this can be closed if either #1386 or #852 are merged in the future.

@andrewgait andrewgait assigned Christian-B and rowleya and unassigned andrewgait Sep 28, 2023
This was linked to pull requests Sep 28, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants