Add mechanism to "reduce" an op to another op

[ctrueden]

Given a set of "op parameters" (name, type and args), the OpMatchingService works in multiple stages:

1. Find the op candidate implementations with matching name and/or type.
2. Narrow down the candidates to exact matches:
   • Filter down to those with the same number of arguments
   • Filter down to those with compatible types of arguments
   • Exclude those that implement Contingent and reject the specific args given

Note that "compatible" above means "able to be converted using the SJC ConvertService."

We will add another phase of the matching process, as follows:

• Define an OpParams class (tentative name) that encapsulates the (name, type, args) as a single object.
• Define some SJC Converter implementations that know how to "reduce" from certain OpParams to other OpParams. This is very useful in the case when an op ends up being a simple wrapper around another op, which is very common.

For example: these converters could define the following reduction path:

• normalize(outputImgPlus, imgPlus, axisTypes)
• ➡️ normalize(outputImg, img, axisIndices)
• ➡️ slicewise(outputImg, img, op(normalize), axisIndices)
• ➡️ map(...)

Then the OpMatchingService would need to—when an exact match is not found—attempt to apply a reduction then repeat the matching algorithm, repeating as needed until no more reductions can be found (excluding cycles).

See the match-conversion branch to follow progress on this issue.

[ctrueden]

We will call the data structure OpArgs.

[ctrueden]

#74 introduces the same OpArgs data structure.

[ctrueden]

@dietzc and I changed our minds, and are going to call it OpRef, since it is basically a "reference" to an op that could exist, should you need it.

[ctrueden]

One thing that wasn't clear in the writeup above (and so I forgot in the intervening months) is that op reduction is really most valuable when a single reduction rule covers multiple different ops. The normalize example above is good, because the first reduction is simply one that looks for any OpRef with a TypedSpace followed by a List<AxisType> axes or List<Axis> axes or AxisType[] axes or Axis[] axes, and reduces it to the same OpRef but with the latter parameter replaced by int[] axisIndices. That is, it is not normalize-specific, but rather lets us write many ops which all use int[] axisIndices and then those other four cases above are all automatically handled, without proliferating wrapper ops everywhere.

Actually, in the above example, we should probably have a single object that holds space+indices, and reduce all representations to that. Will make the op implementations cleaner.

[ctrueden]

One possible issue with this idea is that it makes it harder to fully enumerate all the possible op invocations as compile-safe method signatures (see #19). To accomplish that programmatically, the op reductions would need to be invertible in some sense.

[ctrueden]

@dietzc In light of the above, I think I want to gather some more use cases before committing to this feature, since it will cost substantial work to implement properly. Do you have some intuition for where the op reduction will be most valuable? Do we have a proliferation of op implementations now, or anticipate specific ones in the future, which will be avoided by this scheme?

[ctrueden]

@dietzc and I chatted more, and we still think we want this, but not urgently. When #54 is solved, the situation will be much nicer.

However, it would still be good to document a few concrete use cases for the reducers, where the op ➡️ op translation is not argument-independent (which is what you can achieve with the currently supported single-argument converters). As soon as you want to either: A) add or remove a parameter; or B) have a destination parameter type determined by more than one input parameter type, then having op reduction would be useful.

[ctrueden]

@LeonYang5114 pointed out another potential use case for this.

Suppose you have map(RAI, II) and you want to convert that to map(II, II) to avoid a proliferation of redundant map implementations. The trick is: that II which is derived from the RAI needs to have the same iteration order as the second II. A SciJava Converter cannot achieve this because it is not an argument-independent conversion. But an op reducer could achieve it.

[ctrueden]

Closed in favor of the new scijava-ops work, which includes an "op simplification" framework as well as other related niceties.