Andrew Barnert writes:
On May 8, 2015, at 19:58, Stephen J. Turnbull firstname.lastname@example.org wrote:
Koos Zevenhoven writes:
As a random example, (root @ mean @ square)(x) would produce the right order for rms when using .
Hardly interesting. :-) The result is an exception, as root and square are conceptually scalar-to-scalar, while mean is sequence-to-scalar.
Unless you're using an elementwise square and an array-to-scalar mean, like the ones in NumPy,
Erm, why would square be elementwise and root not? I would suppose that everything is element-wise in Numpy (not a user yet).
in which case it works perfectly well...
But that's an aspect of my point (evidently, obscure). Conceptually, as taught in junior high school or so, root and square are scalar-to- scalar. If you are working in a context such as Numpy where it makes sense to assume they are element-wise and thus composable, the context should provide the compose operator(s). Without that context, Koos's example looks like a TypeError.
But Koos's example, even if it was possibly inadvertent, shows that I may be wrong about that. Maybe compose together with element-wise operators actually _is_ sufficient for something beyond toy examples.
Of course it is!<wink /> I didn't really think there was any doubt about that. I thought the question was whether there's enough commonality among such examples to come up with a Pythonic generic definition of compose, or perhaps a sufficiently compelling example to enshrine its definition as the "usual" interpretation in Python (and let other interpretations overload some operator to get that effect in their contexts).
Of course the fact that we have two groups of people each arguing that obviously the only possible reading of @ is compose/rcompose respectively points out a whole other problem with the idea.
I prefer fgh = f(g(h(-))), but I hardly think it's obvious. Unless you're not Dutch. (If it were obvious to a Dutchman, we'd have it already. <wink />)