lava-nc
IO Process and ProcessModel names are not consistent
Objective of issue: Standard process library IO Processes, ProcessModels, and package names should follow a consistent naming convention.
Lava version:
- [x] 0.6
I'm submitting a ...
- [x] bug report
Current behavior: IO Processes and ProcessModels use several different names and concepts, making it difficult to find the best object for a given requirement. For example, we currently have Source and Sink package and module names, but these contain no Source or Sink classes. Instead they offer RingBuffer, [Hw]SendModel[Precision], and [Hw]ReceiveModel[Precision], with corresponding ProcModels. Additionally, there are receiver and spiker modules with corresponding Processes and ProcessModels that seem like they should be easily merged into the existing IO classes.
Expected behavior: Conceptually, we can enumerate four varieties of IO processes and stick to a single conventional name for each type of Process:
- Classes which generate spikes from internal state, from fixed parameters, from an RNG, etc. can be called SpikeSources. Specific names would be prefixed by the method of creation e.g. BufferSpikeSource, PoissonSpikeSource, FixedIntervalSpikeSource, AerFileSpikeSource, etc.
- Classes which generate spikes from non-spiking input ports can be called SpikeEncoders. Specific names would be TemporalContrastSpikeEncoder (too long?), HoughSpikeEncoder, StepForwardSpikeEncoder, etc.
- Classes which consume spikes to internal state, or otherwise "swallow" output, can be called SpikeSinks. Specific names would be BufferSpikeSink, RateCounterSpikeSink, AerFileSpikeSink, etc.
- Classes which consume spikes to non-spiking output ports can be called SpikeDecoders. Specific names would be RateCounterSpikeDecoder, MovingWindowSpikeDecoder, OneHotPlaceSpikeDecoder, etc.
Alternatively, we could drop the word Spike from all of the above, if the convention that a Generator == Spike Generator is sufficiently respected, and so on. If contributors would try to mix/stretch the definition of Generator to include Float Generators and so on, then it would probably not work to drop it.
Furthermore, if all the IO classes of a given type are collected into a subpackage called SpikeGenerator, for example, then it could be dropped from the class names, but this doesn't work if new IO classes are added elsewhere.
For ProcessModels, names should stick to the [Hw][ProcessName][Precision] naming scheme, e.g. PyFixedIntervalSpikeSourceFloat, NcFixedIntervalSpikeSourceFixed, at least until that system is revisited across Lava.
