refactor!: create ParametrizedFunction interface

[redeboer]

The existing Function interface has too many responsibilities: it (1) converts a DataSample to an array or tensor and (2) distinguishes parameter variables from domain variables. This worked fine so far, because Function was only used when optimizing, where you need to tweak those parameters. In #345 though, we need to a Function that only does (1), for the conversion of one DataSample (four-momenta) to another DataSample (kinematic variables) with different back-ends.

This PR creates a new ParametrizedFunction interface that does (1) and (2) and a 'bare' Function interface that does only (1). The input and output types of the Function interface are generic, so that it can be used in different types of function-like interfaces.

Related changes:

• Renamed LambdifiedFunction to ParametrizedBackendFunction.
• DataTransformer.transform() has become a __call__ and DataTransformer derives from Function.
• Estimator also derives from Function: it computes an estimator value for a set of parameters.

[review-notebook-app]

Check out this pull request on 

See visual diffs & provide feedback on Jupyter Notebooks.

---

Powered by ReviewNB

[redeboer]

@spflueger as discussed, ParametrizedFunction inherits from Function:

tensorwaves/src/tensorwaves/interface.py

Line 32 in 49eae48

class ParametrizedFunction(Function):

This is probably fine with interfaces, but another option would be to give ParametrizedFunction a function attribute. This makes sense if Function were to have more attributes (for instance something like expected_keys, for the input DataSample that its call takes). In that case, composition in the interface of ParametrizedFunction may be safer.

[spflueger]

Looks good & good job. Just two questions about some design choices

[redeboer]

Short summary of offline discussion with @spflueger :

• The Model interface can be removed (refactor!: remove Model interface #357)
• It would be better to create a generic Function interface. The PR has been changed into that, so see the diff fore more details.
• Previous implementation details (see review comments) are only relevant in refactor: adapt implementation to AmpForm v0.12.x #345. They have been removed from this PR.