Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
New syntax for "constant over timestep" variables #720
In some situations, e.g. when using certain state updaters or to avoid re-evaluations of expressions involving random numbers, it would be useful to have a way of declaring a subexpression that is only evaluated once per timestep. The current workaround is to declare the variable as a parameter and update it with
with hopefully a clearer name than "static".
referenced this issue
Jun 20, 2016
The problem I have with this syntax is: when is it evaluated? It doesn't make a difference for
One general thought (related to what I just wrote in #721): if we add a syntax, it might be good to have an explicit syntax for both cases, i.e. something like
I see at least three options:
I think 3 is a bit intransparent, I'd therefore prefer 1 or 2. I have a slight tendency towards 2 because it would be more consistent with what we do in other places (e.g. for
OK, agree with having an explicit syntax for both cases. Should we make that only necessary when there are stateful functions or always necessary? I'd say only when there are stateful functions, with a default of the current behaviour of evaluate-everytime when there are no stateful functions. This does allow for some slight problems in that you might write x=v and hope it means the value of v at the beginning of the timestep and actually it wouldn't always mean that, but this seems relatively unlikely and the saving in unnecessary syntax in the majority of cases seems worth it.
Also agree with having before groups be the default if it matches what we're doing elsewhere (and in any case, this does seem fairly logical). Is there any use case for allowing the user to specify something else? I don't really see any. In which case, it's just a question of the syntax.
One option would be something a bit high level, like
Actually I like
I think this would be the best solution. I.e., you can always set the two options, but you are forced to do it if the expression involves stateful functions. In models like the one used in the
I don't see any immediate use case, but I did not see any for the summed variables either and e.g. the LFP example does need to change the scheduling to work correctly... I think the same approach would be the best: the update happens in a separate object and can therefore be re-scheduled but only with a rather low-level syntax. No need to expose it as an additional keyword argument or anything like that.
Hmm, I have to say I am not convinced... I see the reasoning behind
Ideally, I'd like two have two flags that are somewhat parallel and therefore easily recognizable as alternatives (e.g. just from the names I would not think that
I see what you mean, but I think that
I think it is a long way until we will do approximations based on differences in time scale, that's a tricky topic. The only thing that we already use is the distinction between "constant over a time step" (which we call locally constant in our code) and not. I think it is important that the term makes sense for something like
If I had to vote for something of all that has been proposed so far, I'd probably vote for