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()?),
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 reall
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
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()
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".
http://svn.python.org/projects/python/branches/p3y
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
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,
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 re
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
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
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 func
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
> > sho
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
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
Bill Baxter wrote:
> 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
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
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
> the block as we
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 mor
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
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
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.
> >
>
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)
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) ==> dot(dot(a,dot(b,
23 matches
Mail list logo
