Bill Baxter wrote:
On 3/25/07, Robert Kern [EMAIL PROTECTED] wrote:
Bill Baxter wrote:
I don't know. Given our previous history with convenience functions with
different calling semantics (anyone remember rand()?), I think it probably
will
confuse some people.
I'd really like to see it
On 3/25/07, Colin J. Williams [EMAIL PROTECTED] wrote:
Bill Baxter wrote:
On 3/25/07, Robert Kern [EMAIL PROTECTED] wrote:
Bill Baxter wrote:
I don't know. Given our previous history with convenience functions with
different calling semantics (anyone remember rand()?), I think it
On 3/24/07, Anne Archibald [EMAIL PROTECTED] wrote:
On 24/03/07, Bill Baxter [EMAIL PROTECTED] wrote:
I mentioned in another thread Travis started on the scipy list that I
would find it useful if there were a function like dot() that could
multiply more than just two things.
Here's a
On 24/03/07, Bill Baxter [EMAIL PROTECTED] wrote:
Nice, but how does that fare on things like mdot(a,(b,c),d) ? I'm
pretty sure it doesn't handle it.
I think an mdot that can only multiply things left to right comes up
short compared to an infix operator that can easily use parentheses to
but how about the things like
a = dot(array([8]), ones([1000,1000], array([15])))?
it will be much faster if we will dot 8 x 15 at first, and than the
result to the big array.
D.
Anne Archibald wrote:
On 24/03/07, Bill Baxter [EMAIL PROTECTED] wrote:
Nice, but how does that fare on things
Anne Archibald wrote:
P.S. reduce isn't even a numpy thing, it's one of python's
much-neglected lispy functions.
It looks like reduce(), map(), and filter() are going away for Python
3.0 since GvR believes that they are redundant and list comprehensions
and generator expressions are more
Alan G Isaac wrote:
On Sat, 24 Mar 2007, Steven H. Rogers apparently wrote:
It looks like reduce(), map(), and filter() are going away for Python
3.0 since GvR believes that they are redundant and list comprehensions
and generator expressions are more readable alternatives. lambda was on
On 3/24/07, Steven H. Rogers [EMAIL PROTECTED] wrote:
Anne Archibald wrote:
P.S. reduce isn't even a numpy thing, it's one of python's
much-neglected lispy functions.
It looks like reduce(), map(), and filter() are going away for Python
3.0 since GvR believes that they are redundant
On Mar 24, 2007, at 2:52 PM, Bill Baxter wrote:
On 3/24/07, Steven H. Rogers [EMAIL PROTECTED] wrote:
Anne Archibald wrote:
P.S. reduce isn't even a numpy thing, it's one of python's
much-neglected lispy functions.
It looks like reduce(), map(), and filter() are going away for Python
On 3/24/07, Anne Archibald [EMAIL PROTECTED] wrote:
On 24/03/07, Bill Baxter [EMAIL PROTECTED] wrote:
Nice, but how does that fare on things like mdot(a,(b,c),d) ? I'm
pretty sure it doesn't handle it.
I think an mdot that can only multiply things left to right comes up
short compared
On 3/25/07, Perry Greenfield [EMAIL PROTECTED] wrote:
On Mar 24, 2007, at 2:52 PM, Bill Baxter wrote:
On 3/24/07, Steven H. Rogers [EMAIL PROTECTED] wrote:
Anne Archibald wrote:
P.S. reduce isn't even a numpy thing, it's one of python's
much-neglected lispy functions.
It looks
Perry Greenfield wrote:
On Mar 24, 2007, at 2:52 PM, Bill Baxter wrote:
On 3/24/07, Steven H. Rogers [EMAIL PROTECTED] wrote:
Anne Archibald wrote:
P.S. reduce isn't even a numpy thing, it's one of python's
much-neglected lispy functions.
It looks like reduce(), map(), and filter() are
On Sun, 25 Mar 2007, Bill Baxter apparently wrote:
So if one just
changes the example to
reduce(lambda s, a: s * a.myattr, data, 1)
How does one write that in a simplified way using generator
expressions without calling on reduce?
Eliminating the expressiveness of ``reduce`` has in
On 3/25/07, Steven H. Rogers [EMAIL PROTECTED] wrote:
The generator expression PEP doesn't say this, but the Python 3000
planning PEP (http://www.python.org/dev/peps/pep-3100/) has map() and
filter() on the 'to-be-removed' list with a parenthetic comment that
they can stay. Removal of
Bill Baxter wrote:
On 3/24/07, Anne Archibald [EMAIL PROTECTED] wrote:
You could do this, and for your
own code maybe it's worth it, but I think it would be confusing in the
library.
Could be. Doesn't seem so confusing to me as long as it's documented
clearly in the docstring, but YMMV.
On 3/25/07, Alan G Isaac [EMAIL PROTECTED] wrote:
On Sun, 25 Mar 2007, Bill Baxter apparently wrote:
So if one just
changes the example to
reduce(lambda s, a: s * a.myattr, data, 1)
How does one write that in a simplified way using generator
expressions without calling on reduce?
Bill Baxter wrote:
I think it's fine for filter()/reduce()/map() to be taken out of
builtins and moved to a standard module, but it's not clear that
that's what they're going to do. That py3K web page just says remove
reduce()... done.
On 3/25/07, Robert Kern [EMAIL PROTECTED] wrote:
Bill Baxter wrote:
I think it's fine for filter()/reduce()/map() to be taken out of
builtins and moved to a standard module, but it's not clear that
that's what they're going to do. That py3K web page just says remove
reduce()... done.
On 3/25/07, Robert Kern [EMAIL PROTECTED] wrote:
Bill Baxter wrote:
I don't know. Given our previous history with convenience functions with
different calling semantics (anyone remember rand()?), I think it probably
will
confuse some people.
I'd really like to see it on a cookbook page,
I mentioned in another thread Travis started on the scipy list that I
would find it useful if there were a function like dot() that could
multiply more than just two things.
Here's a sample implementation called 'mdot'.
mdot(a,b,c,d) == dot(dot(dot(a,b),c),d)
mdot(a,(b,c),d) ==
On 24/03/07, Bill Baxter [EMAIL PROTECTED] wrote:
I mentioned in another thread Travis started on the scipy list that I
would find it useful if there were a function like dot() that could
multiply more than just two things.
Here's a sample implementation called 'mdot'.
mdot(a,b,c,d) ==
21 matches
Mail list logo
