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
Returned value needs to be retrieved for object to work #1499
Comments
Hi Jannik, net = Network()
# ...
net.add(PoissonInput(...)) See https://brian2.readthedocs.io/en/stable/user/running.html#networks During the early days of Brian 2 we decided for this mechanism and against a system that would do what you expected here, i.e. something that tracks all the objects that have been created and adds them to the network. One of the reasons is that it makes it more straightforward to have independent simulations, such as in: def sim1():
group1 = NeuronGroup(...)
run(...)
def sim2():
group2 = NeuronGroup(...)
run(...)
# Run simulations
sim1()
sim2() With the current system, Long story short, I think there are pro and cons for different approaches, but I don't think we can revert this basic decision anytime soon (i.e., before creating Brian 3 :) ). All that said, neurons.add_poisson_input(
target_var="v", N=C_ext, rate=nu_ext, weight=J
) |
Thanks, Marcel, for the elaboration! I agree that the concept is fine in general. It may just have to be pointed out to users that the object reference needs to be retrieved. I guess implementing a special case for |
By the way, a related issue would be that Brian doesn't complain if the same variable name is used more than once to store objects like
I think there should be a warning for this as well, which could maybe also be implemented by counting the objects. |
The problem with this is that we want to keep track of instances that are not stored in variables, then we need to keep references to these objects ourselves. Brian 1 actually had a mechanism like that, but it means that if you do e.g. a loop where you re-create objects, then the memory for the unused objects never gets freed.
I think this has the same issues as above – reusing the same variable name is quite common (e.g. when you do a loop, or when you use a function to create objects), and keeping references to all created objects would create memory leaks. Thinking about this a bit more, there might be a way to do something along these lines by hooking into the |
I see the issues... As far as I can tell, the solution that you propose sounds very solid to me. And I guess it will be helpful for many people - probably many are at some point stuck with their Brian code because they don't see what's wrong. If I find some time, I could also try to implement a solution myself and create a PR. |
I have to say I wasn't 100% convinced that this happens very often, but then this morning a post on Discourse described a situation where this warning would have been triggered https://brian.discourse.group/t/synapses-not-functioning/1118 🙃 |
And that was not arranged 😀 |
When defining a
PoissonInput
object, the value returned by the constructor needs to be retrieved for the object to work. While I think that this is not a big issue, it can be confusing because one wouldn't expect the retrieval of the object to make any difference. The same issue might exist for other object types likeNeuronGroup
,SpikeGeneratorGroup
, etc, but for those the practical relevance should be small because the returned object is usually needed by the subsequent code.Here is an example of what works and what doesn't (altered code blocks for this example):
I guess a solution to the issue may be to simply throw a warning if the returned value is not retrieved (in case 2).
The text was updated successfully, but these errors were encountered: