On 9.5.2015 5:58, Stephen J. Turnbull wrote:

Well, you're wrong :-)

Working code:

from numpy import sqrt, mean, square

rms = sqrt(mean(square(x)))

The point is that people have previously described sqrt(mean(square(x))) as root-mean-squared x, not squared-mean-root x. But yes, as I said, it's just one example.

-- Koos

Andrew Barnert writes:

Erm, why would square be elementwise and root not? I would suppose that everything is element-wise in Numpy (not a user yet).

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.

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).

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 />)

On 5/9/2015 6:19 AM, Andrew Barnert via Python-ideas wrote:

I agree that @ is most likely to be usefull in numpy's restricted context.

A composition operator is usually defined by application: f@g(x) is defined as f(g(x)). (I sure there are also axiomatic treatments.) It is an optional syntactic abbreviation. It is most useful in a context where there is one set of data objects, such as the real numbers, or one set + arrays (vectors) defined on the one set; where all function are univariate (or possible multivariate, but that can can be transformed to univariate on vectors); and where parameter names are dummies like 'x', 'y', 'z', or '_'.

The last point is important. Abbreviating h(x) = f(g(x)) with h = f @ g does not lose any information as 'x' is basically a placeholder (so get rid of it). But parameter names are important in most practical contexts, both for understanding a composition and for using it.

dev npv(transfers, discount): '''Return the net present value of discounted transfers.

 transfers: finite iterable of amounts at constant intervals
 discount: fraction per interval
 '''
 divisor = 1 + discount
 return sum(tranfer/divisor**time
             for time, transfer in enumerate(transfers))

Even if one could replace the def statement with npv = <some combination of @, sum, map, add, div, power, enumerate, ...> with parameter names omitted, it would be harder to understand. Using it would require the ability to infer argument types and order from the composed expression.

I intentionally added a statement to calculate the common subexpression prior to the return. I believe it would have to put back in the return expression before converting.

-- Terry Jan Reedy

Hi, I had to answer some of these questions when I wrote Lawvere: https://pypi.python.org/pypi/lawvere

First, there is two kind of composition: pipe and circle so I think a single operator like @ is a bit restrictive. I like "->" and "<-"

Then, for function name and function to string I had to introduce function signature (a tuple). It provides a good tool for decomposition, introspection and comparison in respect with mathematic definition.

Finally, for me composition make sense when you have typed functions otherwise it can easily become a mess and this make composition tied to multiple dispatch.

I really hope composition will be introduced in python but I can't see how it be made without rethinking a good part of function definition.

2015-05-09 17:38 GMT+02:00 Ron Adam ron3200@gmail.com:

> >

      root @ mean @ map $ square(xs)

      compose(root, mean, map(square, xs))

      root ^ mean ^ map & square (xs)

      root ^ mean ^ map & square ^ xs ()

     compose root, of mean, of map with square, of xs

      apply(map(square, xs), mean, root)

      map & square | mean | root (xs)

      xs | map & square | mean | root ()

      apply xs, to map with square, to mean, to root

On Sat, May 9, 2015 at 1:16 PM, Steven D'Aprano steve@pearwood.info wrote:

      root @ mean @ map $ square(xs)

I have trouble seeing the advantage of a special function composition operator when it is easy to write a general 'compose()' function that can produce such things easily enough.

E.g. in a white paper I just did for O'Reilly on _Functional Programming in Python_ I propose this little example implementation:

def compose(*funcs): "Return a new function s.t. compose(f,g,...)(x) == f(g(...(x)))" def inner(data, funcs=funcs): result = data for f in reversed(funcs): result = f(result) return result return inner

Which we might use as:

RMS = compose(root, mean, square) result = RMS(my_array)

-- Keeping medicines from the bloodstreams of the sick; food from the bellies of the hungry; books from the hands of the uneducated; technology from the underdeveloped; and putting advocates of freedom in prisons. Intellectual property is to the 21st century what the slave trade was to the 16th.

On May 9, 2015, at 11:33, Donald Stufft donald@stufft.io wrote:

      root @ mean @ map $ square(xs)

But why?

This is trivial to write.

The nontrivial part is thinking through whether you want left or right compose, what you want to do about multiple arguments, etc. So, unless we can solve _that_ problem by showing that there is one and only one obvious answer, we don't gain anything by implementing one of the many trivial-to-implement possibilities in the stdlib.

Maybe as a recipe in the docs, it would be worth showing two different compose functions to demonstrate how easy it is to write whichever one you want (and how important it is to figure out which one you want).

On May 9, 2015, at 08:38, Ron Adam ron3200@gmail.com wrote:

     root @ mean @ map $ square(xs)

I'm pretty sure that anyone who sees that and doesn't interpret it as meaningless nonsense is going to interpret it as a variation on Haskell and get the wrong intuition.

But, more importantly, this doesn't work. Your square(xs) isn't going to evaluate to a function, but to a whatever falling square on xs returns. (Which is presumably a TypeError, or you wouldn't be looking to map in the first place). And, even if that did work, you're not actually composing a function here anyway; your @ is just a call operator, which we already have in Python, spelled with parens.

     compose(root, mean, map(square, xs))

Now you're not calling square(xs), but you are calling map(square, xs), which is going to return an iterable of squares, not a function; again, you're not composing a function object at all.

And think about how you'd actually write this correctly. You need to either use lambda (which defeats the entire purpose of compose), or partial (which works, but is clumsy and ugly enough without an operator or syntactic sugar that people rarely use it).

     root ^ mean ^ map & square (xs)

     root ^ mean ^ map & square ^ xs ()

    compose root, of mean, of map with square, of xs

But that's not composing. The whole point of compose is that you can compose root of mean of mappings square over some argument to be passed in later, and the result is itself a function over some argument to be passed in later.

What you're doing doesn't add any new abstraction, it just obfuscates normal function application.

     apply(map(square, xs), mean, root)

     map & square | mean | root (xs)

     xs | map & square | mean | root ()

     apply xs, to map with square, to mean, to root

On May 9, 2015, at 20:08, Ron Adam ron3200@gmail.com wrote:

     root @ mean @ map $ square(xs)

@ can't bind more tightly than (). The operator already exists (that's the whole reason people are suggesting it for compose), and it has the same precedence as *.

And even if you could change that, you wouldn't want to. Just as 2 * f(a) calls f on a and then multiplies by 2, b @ f(a) will call f on a and then matrix-multiply it by b; it would be very confusing if it matrix-multiplied b and f and then called the result on a.

I think I know what you're going for here. Half the reason Haskell has an apply operator even though adjacency already means apply is so it can have different precedence from adjacency. And if you don't like that, you can define your own infix operator with a different string of symbols and a different precedence or even associativity but the same body. That allows you to play all kinds of neat tricks like what you're trying to, where you can write almost anything without parentheses and it means exactly what it looks like. Of course you can just as easily write something that means something completely different from what it looks like... But you have to actually work the operators through carefully, not just wave your hands and say "something like this"; when "this" actually doesn't mean what you want it to, you need to define a new operator that does. And, while allowing users to define enough operators to eliminate all the parens and all the lambdas works great for Haskell, I don't think it's a road that Python should follow.

f = root @ mean @ map & square
result = f(xs)

But that means (root @ mean @ map) & square. Assuming you intended function.__and__ to mean partial, you have to write root @ mean @ (map & square), or create a new operator that has the precedence you want.

Exactly: they don't work, either because you've got the precedence wrong, or because you've got an explicit function call rather than something that defines or references a function, and it doesn't make sense to compose that (well, except when the explicit call is to a higher-order function that returns a function, but that wasn't true of any of the examples).

     compose(root, mean, map(square, xs))

I don't understand what you mean. The same thing as what? Neither directly calling the functions, nor your proposed thing, returns a composed function (because, again, the last argument is not a function, it's an iterator returned by a function that you called directly).

Not your syntax. All of your examples that do anything just call a function immediately, rather than defining a function to be called later, so they can't replace uses of lambda. For example, your compose(root, mean, map(square, xs)) doesn't define a new function anywhere, so no part of it can replace a lambda.

The earlier examples actually do attempt to replace uses of lambda. Stephen's compose(root, mean, map square) returns a function. The problem with his suggestion is that map square isn't valid Python syntax--and if it were, that new syntax would be the thing that replaces a need for lambda, not the compose function. Which is obvious if you look at how you'd write that in valid Python syntax: compose(root, mean, lambda xs: map(square, xs)).

I've used the compose(...) form instead of the @ operator form, but the result is exactly the same either way.

I agree with them--but I don't think adding compose to Python, either as a stdlib function or as an operator--actually solves that problem. If we had auto-curried functions and adjacency as apply and a suite of HOFs like flip and custom infix operators and operator sectioning and so on, then the lack of compose would be a problem that forced people to write unnecessary lambda expressions (although still not a huge problem, since it's so trivial to write). But with none of those things, adding compose doesn't actually help you avoid lambdas, except in a few contrived cases. (And maybe in NumPy-like array processing.)