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))

## Computational basis for complex synapse models

### Re: Computational basis for complex synapse models

That would also be a possibility, but I thought of having:
where we would assume that AurynWeight* points to an array of size statesize containing the temporary values.

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);
```

### 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*):
or directly
where here it stores it somewhere else than in the second argument.

What say you?

Code: Select all

```
clear(y);
state_saxpy(1, x1, y);
state_saxpy(-1, x2, y);
```

Code: Select all

```
state_saxpy(-1, x2, x1, y);
```

What say you?

### 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?

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?

### 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 :-/

### 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

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

### 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

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

### 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.

### Re: Computational basis for complex synapse models

I moved our discussion on the BCPNN learning rule to a separate thread https://fzenke.net/auryn/forum/viewtopic.php?f=7&t=54