Consolidate Encode, Decode, and Transcode

[jgosmann]

Motivation and context:
This PR consolidates the Encode, Decode, and Transcode classes into a single Transcode class. The behaviour/expected function signature depends on what arguments of input_vocab, output_vocab, size_in and size_out have been set.

I haven't decided on a final name for Transcode yet and suggestions are welcome. Because it is analogous to a Nengo node SpaNode might work (or may even just Node as we're doing it for Network? But spa.Network can be used as a drop in replacement for nengo.Network, Transcode cannot be used as a drop in replacement for nengo.Node).

Interactions with other PRs:
none

How has this been tested?
existing tests

How long should this take to review?

• Average (neither quick nor lengthy)

Types of changes:

• Breaking change (fix or feature that causes existing functionality to change)

Checklist:

• I have read the CONTRIBUTING.rst document.
• [n/a] I have updated the documentation accordingly.
• I have included a changelog entry.
• [n/a] I have added tests to cover my changes.
• All new and existing tests passed.

Still to do:

• decide on a name for Transcode

[Seanny123]

Is it this a WIP to be discussed during a meeting due to the naming change?

[jgosmann]

This is basically done except for what's not checked on the checklist or in the todo section. It seemed that there was consensus that this is a good idea when I did my nengo_spa presentation.

[Seanny123]

I think you accidentally left some print-statements in the code.

[tcstewar]

This looks really good to me. I like having all three as a single thing. I'm undecided on the name, but right now I'm leaning towards keeping Transcode, although I could be somewhat convinced by spa.Node (but I do think the usage differences are enough that spa.Node may be too confusing).

While playing around it, I did find that a few more useful error messages would be handy. In particular:

    t1 = spa.Transcode('A')

gives this error:

Traceback (most recent call last):
  File "c:\users\terry\documents\github\nengo_gui\nengo_gui\page.py", line 220, in execute
    exec(compiled, code_locals)
  File "<nengo_gui_compiled>", line 50, in <module>
  File "c:\users\terry\documents\github\nengo_spa\nengo_spa\modules\transcode.py", line 148, in __init__
    self.function, self.input_vocab, self.output_vocab),
  File "c:\users\terry\documents\github\nengo_spa\nengo_spa\modules\transcode.py", line 96, in to_node_output
    return SpArrayExtractor(output_vocab)(fn)
  File "c:\users\terry\documents\github\nengo_spa\nengo_spa\modules\transcode.py", line 20, in __call__
    value = self.vocab.parse(value)
AttributeError: 'NoneType' object has no attribute 'parse'

(I'd prefer something like "output_vocab must be specified")

Similarly, this code gives an error at build time:

t2 = spa.Transcode(lambda t: 'A')

Traceback (most recent call last):
  File "c:\users\terry\documents\github\nengo_gui\nengo_gui\page.py", line 503, in runner
    self.sim.step()
  File "c:\users\terry\documents\github\nengo\nengo\simulator.py", line 324, in step
    step_fn()
  File "c:\users\terry\documents\github\nengo\nengo\builder\operator.py", line 752, in step_simpyfunc
    if y is None or not np.all(np.isfinite(y)):
TypeError: ufunc 'isfinite' not supported for the input types, and the inputs could not be safely coerced to any supported types according to the casting rule ''safe''

(I could understand this giving an error at build time if size_out has been specified, but when size_out is not specified the function does have to get evaluated to determine its output size and we should be able to detect that we're getting a string rather than a vector)

[jgosmann]

While playing around it, I did find that a few more useful error messages would be handy.

Added a better error message for the two cases you mentioned.

[Seanny123]

Name-wise, I vote for Node, since it's behaviour is somewhat analogous to nengo.Node and it's very easy to distinguish nengo.Node from spa.Node.

[jgosmann]

I think, I'm leaning more towards Transcode.

[jgosmann]

@Seanny123 Can you approve the PR if there are no more outstanding issues?

I think for know I will stick with Transcode to keep things moving. I'm open to more discussion and changing it later if there is a strong consensus. I'm a bit uncomfortable with spa.Node because oposed to spa.Network it is not just a drop-in replacement for the corresponding Nengo class.

[jgosmann]

(note: I rebased to master and force pushed.)