-
Notifications
You must be signed in to change notification settings - Fork 221
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
Handling of += expressions by Equations() #1219
Comments
Interesting idea. The same would be true of threshold, reset in |
The first thing to do would be to decide the syntax. I suspect |
That was fast, thanks @thesamovar ! I am afraid I have only been working from the wiki as a reference, and have not explored the Equations() code. I am writing some models in collaboration with a group of experimentalists, so making the code as easy to tune as possible for non-programmers was what led me to raise the issue. |
No worries! It's a really interesting and useful idea, and we should have done this from the beginning actually. Maybe the simplest thing is to just have a nice function that just does the same clever substitution stuff as Equations does. |
I may have found a hack-y solution which might be helpful in the meanwhile. Assuming an instantaneous synapse with scaled updating, the following does not work.
A possible work-around is to include ALL parameters in the model, even the ones which are strictly event-driven.
This way, all variables of the model are declared/collected in a single Equations() object, and you can choose to expose only the |
I have to say that I'm not 100% sure I understood the suggestion from the title and the description. Do I understand correctly that by "using Equations" you only mean that you'd like to its substitution mechanism also for statements like
We actually do already have such an object, and it is called... |
That is exactly it! Sorry, I agree the title I chose is rather vague... And I see! I am guessing this is not high priority at all, so after I'm done with a couple of projects here I can have a look at whether we can transfer some of that |
This makes all sense, and I think for consistency the syntax should be exactly like the one for >>> Statements('g += k*w', k=0.3)
Statements('g += 0.3*w')
>>> Statements('g += k*w', g='g_ampa')
Statements('g_ampa += k*w') |
Another (I think preferable) workaround would be to use external variables. I guess you do not want to write them as simple Python variables (i.e. constants = {'tau': 3*ms, k: 0.3}
m = '''dg/dt = -g/tau : siemens'''
m_onpre = '''g += k*w'''
S = Synapses(N_pre, N_post, model=m, on_pre=m_onpre, namespace=constants) |
Ah, that does seem so much better. That way one could collect all the variables for each model in separate namespace dictionaries. Fantastic. Thank you! One of the reasons I am looking at Equations() is, as un-programmer-ly as it sounds, to avoid a soup of variable names like Syn_e_N1_N2_tau, Syn_i_N3_N1_w etc.. As I mentioned, I am writing this particular model in collaboration with people who are not programmers, so I want them to have as clean and easy to understand interface to the code as possible. I think namespaces are definitely the way to go. |
Hi,
While defining equations using Equations() can be very useful when defining models which can then be fine-tuned by substituting variables or values, this method does not seem to work for on_pre and on_post events. If there is a variable which is only used during the events, it will not feature in the model equation (or can be included there as a declaration like 'x : 1'). However, such a declaration cannot be substituted using Equations(), thus limiting the use of Equations() in on_pre and on_post to define flexible models which can be adjusted for various synaptic groups.
Any workarounds/tips would be really helpful. I am not sure if this is strictly an issue, but I think it does limit the use of the very handy Equations() structure.
Cheers
The text was updated successfully, but these errors were encountered: