## Computational basis for complex synapse models

Discussions on development, Auryn's inner workings, adding new features and how to change things at the core
ziegler
Posts: 5
Joined: Mon Jan 12, 2015 5:55 pm

### Re: Computational basis for complex synapse models

sure, that would work.
Did you mean overload state_saxpy and state_mul? with a default value where it is stored (y) and the possibility to store it elsewhere?
And maybe defining that z>N is a one of these temporary vectors (with z<(N+amount of tmp arrays))
zenke
Posts: 156
Joined: Tue Oct 14, 2014 11:34 am
Location: Basel, CH
Contact:

### Re: Computational basis for complex synapse models

That would also be a possibility, but I thought of having:

Code: Select all

void state_mul(NeuronID x, NeuronID y);
void state_mul(NeuronID x, AurynWeight * y);
void state_mul(AurynWeight * x, NeuronID y);
void state_mul(AurynWeight * x, AurynWeight * y);
where we would assume that AurynWeight* points to an array of size statesize containing the temporary values.
ziegler
Posts: 5
Joined: Mon Jan 12, 2015 5:55 pm

### Re: Computational basis for complex synapse models

okay, that's fine. I was only wondering if that would be more efficient to do (for example with x1,x2 NeuronIDs and y a AurynWeight*):

Code: Select all

clear(y);
state_saxpy(1, x1, y);
state_saxpy(-1, x2, y);
or directly

Code: Select all

state_saxpy(-1, x2, x1, y);
where here it stores it somewhere else than in the second argument.
What say you?
zenke
Posts: 156
Joined: Tue Oct 14, 2014 11:34 am
Location: Basel, CH
Contact:

### Re: Computational basis for complex synapse models

I think we should define a more general set of functions for there state vectors anyways. Doing all this with saxpy is getting a bit ... well ... maybe over the top? How about we start a new thread in which we list our desiderata? Right now the whole logic is a mess because I was trying to stay close to GSL and BLAS convention which sometimes stores the result in the first argument, sometimes stores it in the second argument Also saxpy to subtract two vectors which we do fairly often might not be the most optimal. We could have a function state_sub or something like this ...

One could start thinking of fixing this once and for all and also directly provide functions with three arguments (where the third one is optinal). If it is not provided the result is stored in the vector associated with the last argument ... something along those lines, maybe?
zenke
Posts: 156
Joined: Tue Oct 14, 2014 11:34 am
Location: Basel, CH
Contact:

### Re: Computational basis for complex synapse models

But then on a second thought it would be nice to keep the number of such functions really down to a minimum :-/
zenke
Posts: 156
Joined: Tue Oct 14, 2014 11:34 am
Location: Basel, CH
Contact:

### Re: Computational basis for complex synapse models

Hi Lorric,

I thought again a bit on "synaptic state vectors" and I think we should implement all functions on pointers to keep it simple and have getters for getting the pointer via the number. At some point you always have to make the step from z to pointer and we might just as well do that manually. This allows to transparently defining and using temporary vectors along with the matrix stored ones and keeps the overloading of functions at a minimum. So before you start implementing the Zynapse ... give me a couple of hours to get the API into shape.

Cheers,

Friedemann
zenke
Posts: 156
Joined: Tue Oct 14, 2014 11:34 am
Location: Basel, CH
Contact:

### Re: Computational basis for complex synapse models

Re-Hi Lorric,

I pushed an example application sim_bg_lowpass and LPTripletConnection into the github branch dev_complexmatrix. This should demonstrate a typical use case. So far the program compiles and does something, but will have to check further if it does the correct thing. Do you think you can start implementing a Zynapse with these preliminaries?

Cheers,

F
zenke
Posts: 156
Joined: Tue Oct 14, 2014 11:34 am
Location: Basel, CH
Contact:

### Re: Computational basis for complex synapse models

Exciting news! After testing I just merged the dev_complexmatrix branch into master. I also completely reimplemented the functions save_network_state and load_network state to allow to store complex matrix states. They now write to serialized archives to a single binary file, which is much faster and more compact. To create files for inspection the former methods write_to_file still exist for each Connection and SpikingGroup Because I am using boost's stream serialize library it should be straight forward to enable this stream to be gzip compressed as a next step... also the storage of the state of Stimulus and PoissonGroups is still missing, but has become more feasible with the new framework.
zenke