Conciliate pyopy naming with hctsa

[sdvillal]

Properly defining semantics for the main abstractions of the library is important and, of course, it would make things easier to agree as much as possible with the way @benfulcher has given to hctsa.

Ben calls:

• "feature": a single number describing a time series.
• "operation": the mechanism by which a single feature is generated
• his conceptual mapping is 1 feature <-> 1 operation
• has not a good name for functions within .m files

He writes:

I like that every feature has its own operation. Whether we add additional terms for methods that produce multiple outputs is up to the implementation. I guess we need a word for each .m file — I’ve called them code files or methods in the past.

My stand at the moment is:

• We agree for "feature" and "operation"
• I think the mapping 1 operation -> n features makes more sense;
  • reallocation of feature, operation would still be perfectly possible
  • makes for a more natural mapping to software artifacts (whether .m files or python classes)
• We need to name software functions and function calls with concrete parameters.
  • functions can just be functions
  • function calls with concrete parameters could just still be "operations"
  • if overloading operation to also mean "a function call with concrete parameters" is too misleading whenever talking with Ben, we can alternatively use something fun like "curry" (honoring partial application and currying).

To summarise, I would just use "feature", "operator" and "function". Once decided, will need to change the name of the HCTSAFunctionCategory accordingly.

[benfulcher]

Making "operation" mean a function call with specific parameters that outputs 1 or more features would be fine, although inconsistent with the J. Roy. Soc. Interface terminology, in which each operation is a column in the data matrix, and maps R^N -> R. This terminology does not depend on the implementation (i.e., the way in which the feature is generated, either as one output of many from a function, or as the only output of a function). Anything is preferable to "curry"... ;)

[sdvillal]

So we stick with features as scalar values generated by an operation that is a call to a function or operator with concrete parameters. All the needed renaming is done.