We talked recently about writing up the "philosophy of Ops" or some such, to explain the purpose of the library, design goals, etc. Perhaps this javadoc block would be a good place to put that? There is some material in that direction at https://imagej.net/libs/imagej-ops. I don't love that page though; I think we could do a better job describing the intent of the library from a broader and more easily understood perspective.

I wrote a little more, aligned with the bullets in https://imagej.net/libs/imagej-ops, in d723b0e. Let me know what you think @ctrueden

should be considered → are

Does the fact that the number is a floating point number matter for structural equivalence? I.e.: where are we drawing the line with simplification? Number? Real number?

they are likely not result-equivalent due to the underlying data structures → they may not be result-equivalent, for reasons such as implementation differences between the two algorithms, or precision loss when converting between data structures

floating point number matter for structural equivalence? I.e.: where are we drawing the line with simplification? Number? Real number?

I think simplification comes down to "what simplify Ops exist for some concrete type" such as Double or DoubleType

Fixed the other two issues in 4b19d77

This last paragraph should be rewritten. Here is a suggestion:

These definitions of equivalence provide clarity when articulating the Ops framework's various benefits:

1. The ops simplification mechanism enables structural-equivalent ops to be collapsed into a common simplified form, usable with appropriate data structures across programming languages and libraries.
2. ... [out of time to write more today, sorry, but hopefully you see where I'm going with this]

@ctrueden I think this is pretty tricky, but I gave it a go in ed64b87. Let me know what you think.