Hi again. The namespace in Brian is used to resolve anything that is referred to in equations (and other statements like resets, on_pre, …), but is not a variable of the model, i.e. not defined within the equations itself. These external values are always expected to be constant over the run, and to be scalar values. Within “Brian code” (e.g. equations), there is no syntax to access arrays, e.g. you are not allowed to write variable[...]. Of course internally a lot of things are stored as arrays, but all the indexing is handled internally. This is not so much a constraint in general, since for most things were you need arrays these store either one value per neuron (and can therefore be stored as a parameter in a NeuronGroup), or one value per synapse (and can therefore be stored in Synapses). For things like “memory of the past” (like your average recent activity), one would usually use some kind of continuous trace variable like the exponential filter we discussed earlier.
Now, some kind of buffer data structure would be handy sometimes, and we would like to support it (see Introduce a 2d array data structure for buffering · Issue #467 · brian-team/brian2 · GitHub). Unfortunately, at the moment this is not possible using the built-in machinery.
Whenever you run into fundamental limitations of Brian’s code generation framework, you have two options: 1) use a network_operation and write a Python function that does what you’d like to do (you wouldn’t have to write a buffer data structure yourself necessarily, you could also look up the most recent values in a SpikeMonitor, for example) or 2) write a user-defined function in the target language that provides the functionality you are interested in.
Option 1 is the easiest and straightforward, but not compatible with the C++ standalone mode. Option 2 is more complex (and not super-well documented), but it can be compatible with standalone mode if you know how to write C++ code and take care to use the array names that are used internally in Brian’s generated code. You can find some hints in this discussion: User-defined functions
So long story short, you can calculate an average of the spiking activity in the last N time steps with an approach that is compatible with C++ standalone mode, but it is quite a bit of work. My recommendation would be to rather use a continuous activity trace like the one we discussed earlier, which is arguably also more “biologically realistic”.