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

Monitor array return type #88

Closed
thesamovar opened this issue Jul 29, 2013 · 3 comments
Closed

Monitor array return type #88

thesamovar opened this issue Jul 29, 2013 · 3 comments
Assignees
Milestone

Comments

@thesamovar
Copy link
Member

We should decide what M.v should return, and which shape it has.

@thesamovar
Copy link
Member Author

Current thinking suggests the best solution is:

  • M[i].v returns a 1D array corresponding to neuron i
  • M.v is a 2D array, with first index the recorded neuron index and second index time

In general, we shouldn't encourage people to write M.v[i] as this will not be equal to M[i].v.

Plotting multiple recorded traces will be done with plot(M.t, M.v.T).

@mstimberg
Copy link
Member

I implemented the described semantics in a branch (see pull request). The only thing we did not discuss is the possible semantics of using more than one index, e.g. when recording neurons [0, 5, 10], what should mon[[5, 10]] do? I opted for consistent "neuron index first" semantic, so for plotting one would have to transpose:

plot(M.t, M[[5, 10]].v.T)

This means that for fully recorded groups, M[x].v == M.v[x].

I did not bother with slicing support, since this is not really obvious (if [0, 5, 10] is recorded, what should [5:] do -- work as [5, 10] or raise an error about 6, 7, 8, 9?)

@thesamovar
Copy link
Member Author

Nice! I don't think slicing syntax is essential. I'll go ahead and merge this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants