SubPopulation should be extracted from a Population object

Start to implement something, at least for nest2. The idea is just to allow the creation of a Population object withtout creating the cells (addition of a flag create_cells=True by default, but can be set to False). If this is False, then we'll provide to this "empty" population the cells that belongs to it later, in getSubPopulation(). The main problem, now, is that there is a duplication of the positions in both population. So if the user changes them in one population, that will not have a impact on its children. (For the cell parameters, we don't have the problem using the IDs). This is dangerous, so need to fix it (I wont' have the time now, to see later)

I thought about this in detail on the train back from Freiburg. I don't have my notes with me here, but I will post them on Monday. The basic idea is to create a PopulationView class, which has the same behaviour as a Population except for the __init__() method. I think this is a cleaner design than creating an empty Population and having if blocks in __init__().

If this is of interest to the students in Okinawa, I will try to implement it on Monday/Tuesday, but in a simulator-independent way.

The problem with the positions could be resolved by giving the sub-population a reference to the original positions array, but also providing a mask (boolean array) or a slice object allowing to extract only those positions that are relevant to the sub-population.

A sub-population is essentially a view of the original Population object, i.e. the Population is not split, the original Population remains, and it is possible to have multiple sub-populations/views that contain (references to) the same neurons.

Since the Population is not split, I think it is clearer to talk about population views.

A population view/sub-population has all the methods of a full Population. What is different?

• Has a parent attribute
• IDs may be non-consecutive

The main consequence of IDs being non-consecutive is that we have to store them, there is not the option of calculating them.

Should we allow views of views? I can't think of any reason why not.

Potential problems with Projections between views? None that come to mind.

How to select which cells are included in the view, and how to handle the shape/dimensions of a view?

Allow specification of which cells to include as follows:

• slice syntax
• explicit list of cells (as ids or addresses)
• random sample (int n)

For slices, could change the Population.dim attribute to match the shape of the slice. However, it may be better to preserve the dim of the parent.

Implmentation: the cleanest way is probably to define a base class BasePopulation which defines all methods except __init__(), then sub-class this to give Population and PopulationView classes.