itertools has starmap but no starreduce?

Andrey Fedorov wrote:
Is that right, or am I missing something obvious?
How would starreduce differ from normal reduction? The difference between map and starmap is that the former consumes the iterable arguments immediately and produces a list, the latter produces an iterator (and lazily consumes its input as values are retrieved from the iterator). There is no similar distinction to be made in the case of reduce: the only relevant semantic is to consume the entire iterable and produce the final output value. If you're suggesting a new kind of iterator that provides a progress report at each step through the source iterable, that isn't really reduction anymore, so the starreduce name would be misleading. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------

2010/2/12 Andrey Fedorov <anfedorov@gmail.com>:
Is that right, or am I missing something obvious?
The semantics are non-obvious, for one. I assume you mean that the following lines would be equivalent: starreduce(f, iterable, initial) reduce(lambda x,y: f(x, *y), iterable, initial) This is useful for the types of reduction where the result of the function is one type, and the iterable is a sequence of args to that function. For example: reduce(lambda x,y: str.replace(x, *y), (('a', 'aa'), ('b', 'bb',)), some_string) could be written as starreduce(str.replace, (('a', 'aa'), ('b', 'bb',)), some_string) It seems like a very narrow use-case, unless you mean something else. Vitor

On Fri, Feb 12, 2010 at 11:54 AM, Vitor Bosshard <algorias@gmail.com> wrote:
I assume you mean that the following lines would be equivalent:
starreduce(f, iterable, initial)
reduce(lambda x,y: f(x, *y), iterable, initial) Precisely. It seems like a very narrow use-case [...] Agreed, that example is. I also use it for high-level functional stuff - something like Haskell's monads or Java's "chain-of-responsibility". Like: output = reduce(lambda x, f: f(x), chain_of_processors, input) So, given a list [f,g,h], this would be h(g(f(input))). The star-case is when input is a n-touple, and each function works on `n' arguments. But now that I wrote it out without a for loop, it's obviously trivial to add the star in the right place. My mistake! Thanks for helping me catch it :) Cheers, Andrey

On Fri, Feb 12, 2010 at 01:59:45PM -0500, Andrey Fedorov wrote:
Aside: there is no built-in for "lambda x, f: f(x)" somewhere, is there?
apply(f, x) but why do you need it at all? Just call f(x). Oleg. -- Oleg Broytman http://phd.pp.ru/ phd@phd.pp.ru Programmers don't die, they just GOSUB without RETURN.

Andrey Fedorov wrote:
Is that right, or am I missing something obvious?
How would starreduce differ from normal reduction? The difference between map and starmap is that the former consumes the iterable arguments immediately and produces a list, the latter produces an iterator (and lazily consumes its input as values are retrieved from the iterator). There is no similar distinction to be made in the case of reduce: the only relevant semantic is to consume the entire iterable and produce the final output value. If you're suggesting a new kind of iterator that provides a progress report at each step through the source iterable, that isn't really reduction anymore, so the starreduce name would be misleading. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------

2010/2/12 Andrey Fedorov <anfedorov@gmail.com>:
Is that right, or am I missing something obvious?
The semantics are non-obvious, for one. I assume you mean that the following lines would be equivalent: starreduce(f, iterable, initial) reduce(lambda x,y: f(x, *y), iterable, initial) This is useful for the types of reduction where the result of the function is one type, and the iterable is a sequence of args to that function. For example: reduce(lambda x,y: str.replace(x, *y), (('a', 'aa'), ('b', 'bb',)), some_string) could be written as starreduce(str.replace, (('a', 'aa'), ('b', 'bb',)), some_string) It seems like a very narrow use-case, unless you mean something else. Vitor

On Fri, Feb 12, 2010 at 11:54 AM, Vitor Bosshard <algorias@gmail.com> wrote:
I assume you mean that the following lines would be equivalent:
starreduce(f, iterable, initial)
reduce(lambda x,y: f(x, *y), iterable, initial) Precisely. It seems like a very narrow use-case [...] Agreed, that example is. I also use it for high-level functional stuff - something like Haskell's monads or Java's "chain-of-responsibility". Like: output = reduce(lambda x, f: f(x), chain_of_processors, input) So, given a list [f,g,h], this would be h(g(f(input))). The star-case is when input is a n-touple, and each function works on `n' arguments. But now that I wrote it out without a for loop, it's obviously trivial to add the star in the right place. My mistake! Thanks for helping me catch it :) Cheers, Andrey

On Fri, Feb 12, 2010 at 01:59:45PM -0500, Andrey Fedorov wrote:
Aside: there is no built-in for "lambda x, f: f(x)" somewhere, is there?
apply(f, x) but why do you need it at all? Just call f(x). Oleg. -- Oleg Broytman http://phd.pp.ru/ phd@phd.pp.ru Programmers don't die, they just GOSUB without RETURN.
participants (4)
-
Andrey Fedorov
-
Nick Coghlan
-
Oleg Broytman
-
Vitor Bosshard