Tim Peters writes:
> "Sum reduction" and "running-sum accumulation" are primitives in
> many peoples' brains.
I wonder what Kahneman would say about that. He goes to some length
to explain that people are quite good (as human abilities go) at
perceiving averages over sets but terrible at summi
Greg Ewing writes:
> Kyle Lahnakoski wrote:
>
> > Consider Serhiy Storchaka's elegant solution, which I reformatted for
> > readability
> >
> >>smooth_signal = [
> >> average
> >>for average in [0]
> >>for x in signal
> >> for average in [(1-decay)*average + decay*x]
>
[Peter O'Connor ]
> Ok, so it seems everyone's happy with adding an initial_value argument.
Heh - that's not clear to me ;-)
> Now, I claim that while it should be an option, the initial value should NOT
> be returned by default. (i.e. the returned generator should by default
> yield N elements
* correction to brackets from first example:
def iter_cumsum_tolls_from_day(day, toll_amount_so_far):
return accumulate(get_tolls_from_day(day), initial=toll_amount_so_far)
On Mon, Apr 9, 2018 at 11:55 PM, Peter O'Connor
wrote:
> Ok, so it seems everyone's happy with adding an initial_valu
Ok, so it seems everyone's happy with adding an initial_value argument.
Now, I claim that while it should be an option, the initial value should
NOT be returned by default. (i.e. the returned generator should by default
yield N elements, not N+1).
Example: suppose we're doing the toll booth thin
[Tim]
>> while we have N numbers, there are N+1 slice indices. So
>> accumulate(xs) doesn't quite work. It needs to also have a 0 inserted
>> as the first prefix sum (the empty prefix sum(xs[:0]).
>>
>> Which is exactly what a this_is_the_initial_value=0 argument would do
>> for us.
[Greg Ewing
I continue to find all this weird new syntax to create absurdly long
one-liners confusing and mysterious. Python is not Perl for a reason.
On Mon, Apr 9, 2018, 5:55 PM Peter O'Connor
wrote:
> Kyle, you sounded so reasonable when you were trashing
> itertools.accumulate (which I now agree is horr
On 9 April 2018 at 22:10, Brett Cannon wrote:
>
>
> On Mon, 9 Apr 2018 at 05:18 Joao S. O. Bueno wrote:
>>
>> we could even call this approach a name such as "function call".
>
>
> The harsh sarcasm is not really called for.
Indeed - on rereading, I have to agree on that.
I do apologize for th
Tim Peters wrote:
while we have N numbers, there are N+1 slice indices. So
accumulate(xs) doesn't quite work. It needs to also have a 0 inserted
as the first prefix sum (the empty prefix sum(xs[:0]).
Which is exactly what a this_is_the_initial_value=0 argument would do
for us.
In this case,
On Mon, 9 Apr 2018 at 05:18 Joao S. O. Bueno wrote:
> I have an idea for an inovative, unanbiguous, straightforward and
> backwards compatible syntax for that,
> that evena llows one to pass metadata along the operation so that the
> results can be tweaked acording
> to each case's needs.
>
> Wha
Peter O'Connor wrote:
The behaviour where the first element of the return is the same as the
first element of the input can be weird and confusing. E.g. compare:
>> list(itertools.accumulate([2, 3, 4], lambda accum, val: accum-val))
[2, -1, -5]
>> list(itertools.accumulate([2, 3, 4], lambda
Woo hoo! Another coincidence. I just happened to be playing with
this problem today:
You have a large list - xs - of N numbers. It's necessary to compute slice sums
sum(xs[i:j])
for a great many slices, 0 <= i <= j <= N.
For concreteness, say xs is a time series representing a toll booth
Kyle, you sounded so reasonable when you were trashing itertools.accumulate
(which I now agree is horrible). But then you go and support Serhiy's
madness: "smooth_signal = [average for average in [0] for x in signal for
average in [(1-decay)*average + decay*x]]" which I agree is clever, but
reads
On Friday, April 6, 2018 at 9:03:05 PM UTC-4, Raymond Hettinger wrote:
>
> > On Friday, April 6, 2018 at 8:14:30 AM UTC-7, Guido van Rossum wrote:
> > On Fri, Apr 6, 2018 at 7:47 AM, Peter O'Connor
> wrote:
> >> So some more humble proposals would be:
> >>
> >> 1) An initializer to iterto
[Tim]
>> Then why was [accumulate] generalized to allow any 2-argument function?
[Raymond]
> Prior to 3.2, accumulate() was in the recipes section as pure Python
> code. It had no particular restriction to numeric types.
>
> I received a number of requests for accumulate() to be promoted
> to a r
Also Tim Peter's one-line example of:
print(list(itertools.accumulate([1, 2, 3], lambda x, y: str(x) + str(y
I think makes it clear that itertools.accumulate is not the right vehicle
for this change - we should make a new itertools function with a required
"initial" argument.
On Mon, Apr 9,
It seems clear that the name "accumulate" has been kind of antiquated since
the "func" argument was added and "sum" became just a default.
And people seem to disagree about whether the result should have a length N
or length N+1 (where N is the number of elements in the input iterable).
The behav
No worries, already implemented features happens so often in this list that
there's a story about Guido going back in a time machine to implement them
;-)
Just wanted to check that I had understood what you suggested correctly
On 9 April 2018 at 12:42, Andrés Delfino wrote:
> Sorry, I didn't kn
I have an idea for an inovative, unanbiguous, straightforward and
backwards compatible syntax for that,
that evena llows one to pass metadata along the operation so that the
results can be tweaked acording
to each case's needs.
What about:
new_data = dict_feed({
"direct": "some data",
I'm sorry that I didn't send a copy of the discussions here.
-- Forwarded message --
From: Thautwarm Zhao
Date: 2018-04-09 1:24 GMT+08:00
Subject: Re: [Python-ideas] Is there any idea about dictionary destructing?
To: "Eric V. Smith"
Thank you, Eric. Your links really help me a
Sorry, I didn't know that kwargs unpacking in dictionaries displays don't
raise a TypeError exception.
On Mon, Apr 9, 2018 at 8:23 AM, Daniel Moisset
wrote:
> In which way would this be different to {**mapping1, **mapping2,
> **mapping3} ?
>
> On 8 April 2018 at 22:18, Andrés Delfino wrote:
>
>
In which way would this be different to {**mapping1, **mapping2,
**mapping3} ?
On 8 April 2018 at 22:18, Andrés Delfino wrote:
> Hi!
>
> I thought that maybe dict could accept several mappings as positional
> arguments, like this:
>
> class Dict4(dict):
>> def __init__(self, *args, **kwargs)
On 9 April 2018 at 14:38, Raymond Hettinger wrote:
>> On Apr 8, 2018, at 6:43 PM, Tim Peters wrote:
>> In short, for _general_ use `accumulate()` needs `initial` for exactly
>> the same reasons `reduce()` needed it.
>
> The reduce() function had been much derided, so I've had it mentally filed in
On 09/04/18 11:52, Rhodri James wrote:
On 07/04/18 09:54, Cammil Taank wrote:
Care to repeat those arguments?
Indeed.
*Minimal use of characters*
Terseness is not necessarily a virtue. While it's good not to be
needlessly verbose, Python is not Perl and we are not trying to do
everything
On 07/04/18 09:54, Cammil Taank wrote:
Care to repeat those arguments?
Indeed.
*Minimal use of characters*
Terseness is not necessarily a virtue. While it's good not to be
needlessly verbose, Python is not Perl and we are not trying to do
everything on one line. Overly terse code is much
On 9 April 2018 at 01:01, Steven D'Aprano wrote:
> On Sun, Apr 08, 2018 at 09:25:33PM +1000, Nick Coghlan wrote:
>
>> I was writing a new stdlib test case today, and thinking about how I
>> might structure it differently in a PEP 572 world, and realised that a
>> situation the next version of the
Raymond Hettinger wrote:
I don't want to overstate the case, but I do think a function signature that
offers a "first_value" option is an invitation to treat the first value as
being distinct from the rest of the data stream.
I conjecture that the initial value is *always* special,
and the onl
27 matches
Mail list logo
