Moving/rolling average implementations ?

> Le 12 avr. 2020 à 12:19, Richard O'Keefe <[hidden email]> a écrit :
>
> 
> I have coded and benchmarked 8 different running mean algorithms.
> In the presence of inexact numbers it is not as accurate as
> redoing the sums, but it's pretty close, and it's fast.
> If "width" is not an integer or is out of range, an error
> will be reported by #new: or #at:[put:].  It's based on Welford's
> stable update.
>
> Of course this approach does NOT work for trimmed or Winsorised
> means or for medians or any kind of robust estimate of location.
>
> SequenceableCollection
>   methods for: 'summarising'
>     runningMeans: width
>       |a m d|
>       a := Array new: self size - width + 1.
>       m := 0.
>       1 to: width do: [:i |
>         m := (self at: i) + m].
>       m := m / width.  
>       d := 1.
>       a at: d put: m.
>       width + 1 to: self size do: [:i |
>         m := ((self at: i) - (self at: d)) / width + m.
>         d := d + 1.
>         a at: d put: m].
>       ^a
>      
>  
>
>
>

> I would vote for inclusion in the base image ?
> With your explanation as comments.
>
> I’ll play with it.
>
> Thanks
> Cedrick
>
>> Le 12 avr. 2020 à 12:19, Richard O'Keefe <[hidden email]> a écrit :
>>
>> 
>> I have coded and benchmarked 8 different running mean algorithms.
>> In the presence of inexact numbers it is not as accurate as
>> redoing the sums, but it's pretty close, and it's fast.
>> If "width" is not an integer or is out of range, an error
>> will be reported by #new: or #at:[put:].  It's based on Welford's
>> stable update.
>>
>> Of course this approach does NOT work for trimmed or Winsorised
>> means or for medians or any kind of robust estimate of location.
>>
>> SequenceableCollection
>>  methods for: 'summarising'
>>    runningMeans: width
>>      |a m d|
>>      a := Array new: self size - width + 1.
>>      m := 0.
>>      1 to: width do: [:i |
>>        m := (self at: i) + m].
>>      m := m / width.  
>>      d := 1.
>>      a at: d put: m.
>>      width + 1 to: self size do: [:i |
>>        m := ((self at: i) - (self at: d)) / width + m.
>>        d := d + 1.
>>        a at: d put: m].
>>      ^a
>>
>>
>>
>>
>>
>

> Le 12 avr. 2020 à 14:22, Sven Van Caekenberghe <[hidden email]> a écrit :
>
>
>
>> On 12 Apr 2020, at 13:53, Cédrick Béler <[hidden email]> wrote:
>>
>> Beautiful ^^
>
> I also like it.
>
> But why the single letter variable names ? Why not:
>
> SequenceableCollection>>#runningMeans: width
>  | means sum index |
>  means := Array new: self size - width + 1.
>  sum := 0.
>  1 to: width do: [ :each |
>    sum := sum + (self at: each) ].
>  index := 1.
>  means at: index put: sum / width.
>  width + 1 to: self size do: [ :each |
>    sum := sum - (self at: index) + (self at: each).
>    index := index + 1.
>    means at: index put: sum / width ].
>  ^ means
>
> A good comment, a correct initial bounds check and unit tests are also needed.
>
>> I would vote for inclusion in the base image ?
>> With your explanation as comments.
>>
>> I’ll play with it.
>>
>> Thanks
>> Cedrick
>>
>>> Le 12 avr. 2020 à 12:19, Richard O'Keefe <[hidden email]> a écrit :
>>>
>>> 
>>> I have coded and benchmarked 8 different running mean algorithms.
>>> In the presence of inexact numbers it is not as accurate as
>>> redoing the sums, but it's pretty close, and it's fast.
>>> If "width" is not an integer or is out of range, an error
>>> will be reported by #new: or #at:[put:].  It's based on Welford's
>>> stable update.
>>>
>>> Of course this approach does NOT work for trimmed or Winsorised
>>> means or for medians or any kind of robust estimate of location.
>>>
>>> SequenceableCollection
>>> methods for: 'summarising'
>>>   runningMeans: width
>>>     |a m d|
>>>     a := Array new: self size - width + 1.
>>>     m := 0.
>>>     1 to: width do: [:i |
>>>       m := (self at: i) + m].
>>>     m := m / width.  
>>>     d := 1.
>>>     a at: d put: m.
>>>     width + 1 to: self size do: [:i |
>>>       m := ((self at: i) - (self at: d)) / width + m.
>>>       d := d + 1.
>>>       a at: d put: m].
>>>     ^a
>>>
>>>
>>>
>>>
>>>
>>
>
>

>
>
>
> > On 12 Apr 2020, at 13:53, Cédrick Béler <[hidden email]> wrote:
> >
> > Beautiful ^^
>
> I also like it.
>
> But why the single letter variable names ? Why not:
>
> SequenceableCollection>>#runningMeans: width
>   | means sum index |
>   means := Array new: self size - width + 1.
>   sum := 0.
>   1 to: width do: [ :each |
>     sum := sum + (self at: each) ].
>   index := 1.
>   means at: index put: sum / width.
>   width + 1 to: self size do: [ :each |
>     sum := sum - (self at: index) + (self at: each).
>     index := index + 1.
>     means at: index put: sum / width ].
>   ^ means
>
> A good comment, a correct initial bounds check and unit tests are also needed.
>
> > I would vote for inclusion in the base image ?
> > With your explanation as comments.
> >
> > I’ll play with it.
> >
> > Thanks
> > Cedrick
> >
> >> Le 12 avr. 2020 à 12:19, Richard O'Keefe <[hidden email]> a écrit :
> >>
> >> 
> >> I have coded and benchmarked 8 different running mean algorithms.
> >> In the presence of inexact numbers it is not as accurate as
> >> redoing the sums, but it's pretty close, and it's fast.
> >> If "width" is not an integer or is out of range, an error
> >> will be reported by #new: or #at:[put:].  It's based on Welford's
> >> stable update.
> >>
> >> Of course this approach does NOT work for trimmed or Winsorised
> >> means or for medians or any kind of robust estimate of location.
> >>
> >> SequenceableCollection
> >>  methods for: 'summarising'
> >>    runningMeans: width
> >>      |a m d|
> >>      a := Array new: self size - width + 1.
> >>      m := 0.
> >>      1 to: width do: [:i |
> >>        m := (self at: i) + m].
> >>      m := m / width.
> >>      d := 1.
> >>      a at: d put: m.
> >>      width + 1 to: self size do: [:i |
> >>        m := ((self at: i) - (self at: d)) / width + m.
> >>        d := d + 1.
> >>        a at: d put: m].
> >>      ^a
> >>
> >>
> >>
> >>
> >>
> >
>
>

> Le 13 avr. 2020 à 04:47, Richard O'Keefe <[hidden email]> a écrit :
>
> I did mention that it was one of eight implementations that I tried.
> In fact you broke it with your change.
> It is important ***NOT*** to keep a running sum but a running MEAN.
> The line
>    m := ((self at: i) - (self at: d)) / width + m
> was written that way for a reason.
>
> I did think of renaming the variables for general use, but decided to display
> the actual code that I tested.  If you want polished code, here it is.
>
>    runningMeans: width
>      "This returns an array of running means as if the receiver
>       were broken into overlapping segments 'width' long and the
>       mean of each calculated.  This uses an adaptation of
>       Welford's algorithm for stably updating the mean; it is
>       important to maintain a current MEAN not a current SUM.
>       This has been tested against 7 other algorithms.  It was
>       the most accurate of the faster ones.  The result is an
>       Array no matter what kind of sequence the receiver is.
>       If the receiver is a tree (like a virtual concatenation)
>       or a singly or doubly linked list you should convert the
>       receiver to an Array first.  Note that there is no
>       explicit check that width is an Integer or is in range;
>       none is needed because those checks happen anyway."
>      |result mean resultIndex|
>      result := Array new: self size - width + 1.
>      mean := 0.
>      1 to: width do: [:i | mean := (self at: i) + mean].
>      mean := mean / width.
>      resultIndex := 1.
>      result at: resultIndex put: mean.
>      width + 1 to: self size do: [:i |
>        mean := ((self at: i) - (self at: resultIndex)) / width + mean.
>        resultIndex := resultIndex + 1.
>        result at: resultIndex put: mean].
>      ^result
>
>
>
> On Mon, 13 Apr 2020 at 00:23, Sven Van Caekenberghe <[hidden email]> wrote:
>>
>>
>>
>>> On 12 Apr 2020, at 13:53, Cédrick Béler <[hidden email]> wrote:
>>>
>>> Beautiful ^^
>>
>> I also like it.
>>
>> But why the single letter variable names ? Why not:
>>
>> SequenceableCollection>>#runningMeans: width
>>  | means sum index |
>>  means := Array new: self size - width + 1.
>>  sum := 0.
>>  1 to: width do: [ :each |
>>    sum := sum + (self at: each) ].
>>  index := 1.
>>  means at: index put: sum / width.
>>  width + 1 to: self size do: [ :each |
>>    sum := sum - (self at: index) + (self at: each).
>>    index := index + 1.
>>    means at: index put: sum / width ].
>>  ^ means
>>
>> A good comment, a correct initial bounds check and unit tests are also needed.
>>
>>> I would vote for inclusion in the base image ?
>>> With your explanation as comments.
>>>
>>> I’ll play with it.
>>>
>>> Thanks
>>> Cedrick
>>>
>>>> Le 12 avr. 2020 à 12:19, Richard O'Keefe <[hidden email]> a écrit :
>>>>
>>>> 
>>>> I have coded and benchmarked 8 different running mean algorithms.
>>>> In the presence of inexact numbers it is not as accurate as
>>>> redoing the sums, but it's pretty close, and it's fast.
>>>> If "width" is not an integer or is out of range, an error
>>>> will be reported by #new: or #at:[put:].  It's based on Welford's
>>>> stable update.
>>>>
>>>> Of course this approach does NOT work for trimmed or Winsorised
>>>> means or for medians or any kind of robust estimate of location.
>>>>
>>>> SequenceableCollection
>>>> methods for: 'summarising'
>>>>   runningMeans: width
>>>>     |a m d|
>>>>     a := Array new: self size - width + 1.
>>>>     m := 0.
>>>>     1 to: width do: [:i |
>>>>       m := (self at: i) + m].
>>>>     m := m / width.
>>>>     d := 1.
>>>>     a at: d put: m.
>>>>     width + 1 to: self size do: [:i |
>>>>       m := ((self at: i) - (self at: d)) / width + m.
>>>>       d := d + 1.
>>>>       a at: d put: m].
>>>>     ^a
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>

>
> Fully agree on proper names.
>
> === I don’t know if this is because of free confinement time but I can keep on asking questions so I share some I hope will make sense (for the sake of discussion).
>
> For instance, I'm wondering if tests on conditions so as to raise proper exceptions is a good practice (for instance if the  width object does not make sense, like a float) #doesNotMakeSense btw would be a cool name for the « maybe » cases Richard was talking.
>
> Then I asked myself what are the drawbacks (especially on performance) on adding extra information to source code (a bit like longer variable names) ?
>
> There is the raw code and the sources code file that helps separating concerns. At least we don’t mind at all having longer literals (variables names, …).
>
> I cannot help is what about pragmas. I kind see roughly how they work. But is it possible to distinguish between runtime / source only pragmas (not sure I’m clear here but it seems to me that some are important for documentation purposes that are not needed at runtime) ?
>
> Also, I’ve never really liked method categories. I don’t really see how there are implemented but they don’t feel nice to me.
> Could they be only pragmas ?
>
>
>
>
>
> Happy eater Sunday, stay all preserved (sad day for the game of life),
>
> Cédrick
>
>
>
> > Le 12 avr. 2020 à 14:22, Sven Van Caekenberghe <[hidden email]> a écrit :
> >
> >
> >
> >> On 12 Apr 2020, at 13:53, Cédrick Béler <[hidden email]> wrote:
> >>
> >> Beautiful ^^
> >
> > I also like it.
> >
> > But why the single letter variable names ? Why not:
> >
> > SequenceableCollection>>#runningMeans: width
> >  | means sum index |
> >  means := Array new: self size - width + 1.
> >  sum := 0.
> >  1 to: width do: [ :each |
> >    sum := sum + (self at: each) ].
> >  index := 1.
> >  means at: index put: sum / width.
> >  width + 1 to: self size do: [ :each |
> >    sum := sum - (self at: index) + (self at: each).
> >    index := index + 1.
> >    means at: index put: sum / width ].
> >  ^ means
> >
> > A good comment, a correct initial bounds check and unit tests are also needed.
> >
> >> I would vote for inclusion in the base image ?
> >> With your explanation as comments.
> >>
> >> I’ll play with it.
> >>
> >> Thanks
> >> Cedrick
> >>
> >>> Le 12 avr. 2020 à 12:19, Richard O'Keefe <[hidden email]> a écrit :
> >>>
> >>> 
> >>> I have coded and benchmarked 8 different running mean algorithms.
> >>> In the presence of inexact numbers it is not as accurate as
> >>> redoing the sums, but it's pretty close, and it's fast.
> >>> If "width" is not an integer or is out of range, an error
> >>> will be reported by #new: or #at:[put:].  It's based on Welford's
> >>> stable update.
> >>>
> >>> Of course this approach does NOT work for trimmed or Winsorised
> >>> means or for medians or any kind of robust estimate of location.
> >>>
> >>> SequenceableCollection
> >>> methods for: 'summarising'
> >>>   runningMeans: width
> >>>     |a m d|
> >>>     a := Array new: self size - width + 1.
> >>>     m := 0.
> >>>     1 to: width do: [:i |
> >>>       m := (self at: i) + m].
> >>>     m := m / width.
> >>>     d := 1.
> >>>     a at: d put: m.
> >>>     width + 1 to: self size do: [:i |
> >>>       m := ((self at: i) - (self at: d)) / width + m.
> >>>       d := d + 1.
> >>>       a at: d put: m].
> >>>     ^a
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >
> >
>
>

> Le 13 avr. 2020 à 10:48, Cédrick Béler <[hidden email]> a écrit :
>
> What about this test (in OrderedCollectionTest - it suggests a Trait too) ?
>
> testRunningMeans
>
> | result col |
> col := #(1 1 2 2 3 3) asOrderedCollection.
> result := col runningMeans: 2.
>
> self assert: (result = {1. (3/2). 2. (5/2). 3}).
>
> self assert: (result class = Array).
>
> self assert: result size <= (col size). "Running means with 1 has little interest ?"
>
> self should: [ col runningMeans: 7 ] raise: SubscriptOutOfBounds.
> self  should: [ col runningMeans: -2 ] raise: SubscriptOutOfBounds.
> self  should: [ col runningMeans: 1.3 ] raise: Error withExceptionDo: [ :anException | self assert: anException messageText equals: 'primitive #basicNew: in Array class failed’ ]
>
>
> Cheers,
> Cédrick
>
>> Le 13 avr. 2020 à 04:47, Richard O'Keefe <[hidden email]> a écrit :
>>
>> I did mention that it was one of eight implementations that I tried.
>> In fact you broke it with your change.
>> It is important ***NOT*** to keep a running sum but a running MEAN.
>> The line
>>   m := ((self at: i) - (self at: d)) / width + m
>> was written that way for a reason.
>>
>> I did think of renaming the variables for general use, but decided to display
>> the actual code that I tested.  If you want polished code, here it is.
>>
>>   runningMeans: width
>>     "This returns an array of running means as if the receiver
>>      were broken into overlapping segments 'width' long and the
>>      mean of each calculated.  This uses an adaptation of
>>      Welford's algorithm for stably updating the mean; it is
>>      important to maintain a current MEAN not a current SUM.
>>      This has been tested against 7 other algorithms.  It was
>>      the most accurate of the faster ones.  The result is an
>>      Array no matter what kind of sequence the receiver is.
>>      If the receiver is a tree (like a virtual concatenation)
>>      or a singly or doubly linked list you should convert the
>>      receiver to an Array first.  Note that there is no
>>      explicit check that width is an Integer or is in range;
>>      none is needed because those checks happen anyway."
>>     |result mean resultIndex|
>>     result := Array new: self size - width + 1.
>>     mean := 0.
>>     1 to: width do: [:i | mean := (self at: i) + mean].
>>     mean := mean / width.
>>     resultIndex := 1.
>>     result at: resultIndex put: mean.
>>     width + 1 to: self size do: [:i |
>>       mean := ((self at: i) - (self at: resultIndex)) / width + mean.
>>       resultIndex := resultIndex + 1.
>>       result at: resultIndex put: mean].
>>     ^result
>>
>>
>>
>> On Mon, 13 Apr 2020 at 00:23, Sven Van Caekenberghe <[hidden email]> wrote:
>>>
>>>
>>>
>>>> On 12 Apr 2020, at 13:53, Cédrick Béler <[hidden email]> wrote:
>>>>
>>>> Beautiful ^^
>>>
>>> I also like it.
>>>
>>> But why the single letter variable names ? Why not:
>>>
>>> SequenceableCollection>>#runningMeans: width
>>> | means sum index |
>>> means := Array new: self size - width + 1.
>>> sum := 0.
>>> 1 to: width do: [ :each |
>>>   sum := sum + (self at: each) ].
>>> index := 1.
>>> means at: index put: sum / width.
>>> width + 1 to: self size do: [ :each |
>>>   sum := sum - (self at: index) + (self at: each).
>>>   index := index + 1.
>>>   means at: index put: sum / width ].
>>> ^ means
>>>
>>> A good comment, a correct initial bounds check and unit tests are also needed.
>>>
>>>> I would vote for inclusion in the base image ?
>>>> With your explanation as comments.
>>>>
>>>> I’ll play with it.
>>>>
>>>> Thanks
>>>> Cedrick
>>>>
>>>>> Le 12 avr. 2020 à 12:19, Richard O'Keefe <[hidden email]> a écrit :
>>>>>
>>>>> 
>>>>> I have coded and benchmarked 8 different running mean algorithms.
>>>>> In the presence of inexact numbers it is not as accurate as
>>>>> redoing the sums, but it's pretty close, and it's fast.
>>>>> If "width" is not an integer or is out of range, an error
>>>>> will be reported by #new: or #at:[put:].  It's based on Welford's
>>>>> stable update.
>>>>>
>>>>> Of course this approach does NOT work for trimmed or Winsorised
>>>>> means or for medians or any kind of robust estimate of location.
>>>>>
>>>>> SequenceableCollection
>>>>> methods for: 'summarising'
>>>>>  runningMeans: width
>>>>>    |a m d|
>>>>>    a := Array new: self size - width + 1.
>>>>>    m := 0.
>>>>>    1 to: width do: [:i |
>>>>>      m := (self at: i) + m].
>>>>>    m := m / width.
>>>>>    d := 1.
>>>>>    a at: d put: m.
>>>>>    width + 1 to: self size do: [:i |
>>>>>      m := ((self at: i) - (self at: d)) / width + m.
>>>>>      d := d + 1.
>>>>>      a at: d put: m].
>>>>>    ^a
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>

> Of course, to get the most from method categories, the method
> categories need to be documented, and you need to keep them as up to
> date as any other part of the source code.
>
> I can say that the discipline of trying to come up with meaningful
> categories and use them consistently has improved the quality of my
> code.
>
> On Mon, 13 Apr 2020 at 00:38, Cédrick Béler <[hidden email]> wrote:
>>
>> Fully agree on proper names.
>>
>> === I don’t know if this is because of free confinement time but I can keep on asking questions so I share some I hope will make sense (for the sake of discussion).
>>
>> For instance, I'm wondering if tests on conditions so as to raise proper exceptions is a good practice (for instance if the  width object does not make sense, like a float) #doesNotMakeSense btw would be a cool name for the « maybe » cases Richard was talking.
>>
>> Then I asked myself what are the drawbacks (especially on performance) on adding extra information to source code (a bit like longer variable names) ?
>>
>> There is the raw code and the sources code file that helps separating concerns. At least we don’t mind at all having longer literals (variables names, …).
>>
>> I cannot help is what about pragmas. I kind see roughly how they work. But is it possible to distinguish between runtime / source only pragmas (not sure I’m clear here but it seems to me that some are important for documentation purposes that are not needed at runtime) ?
>>
>> Also, I’ve never really liked method categories. I don’t really see how there are implemented but they don’t feel nice to me.
>> Could they be only pragmas ?
>>
>>
>>
>>
>>
>> Happy eater Sunday, stay all preserved (sad day for the game of life),
>>
>> Cédrick
>>
>>
>>
>>> Le 12 avr. 2020 à 14:22, Sven Van Caekenberghe <[hidden email]> a écrit :
>>>
>>>
>>>
>>>> On 12 Apr 2020, at 13:53, Cédrick Béler <[hidden email]> wrote:
>>>>
>>>> Beautiful ^^
>>>
>>> I also like it.
>>>
>>> But why the single letter variable names ? Why not:
>>>
>>> SequenceableCollection>>#runningMeans: width
>>> | means sum index |
>>> means := Array new: self size - width + 1.
>>> sum := 0.
>>> 1 to: width do: [ :each |
>>>   sum := sum + (self at: each) ].
>>> index := 1.
>>> means at: index put: sum / width.
>>> width + 1 to: self size do: [ :each |
>>>   sum := sum - (self at: index) + (self at: each).
>>>   index := index + 1.
>>>   means at: index put: sum / width ].
>>> ^ means
>>>
>>> A good comment, a correct initial bounds check and unit tests are also needed.
>>>
>>>> I would vote for inclusion in the base image ?
>>>> With your explanation as comments.
>>>>
>>>> I’ll play with it.
>>>>
>>>> Thanks
>>>> Cedrick
>>>>
>>>>> Le 12 avr. 2020 à 12:19, Richard O'Keefe <[hidden email]> a écrit :
>>>>>
>>>>> 
>>>>> I have coded and benchmarked 8 different running mean algorithms.
>>>>> In the presence of inexact numbers it is not as accurate as
>>>>> redoing the sums, but it's pretty close, and it's fast.
>>>>> If "width" is not an integer or is out of range, an error
>>>>> will be reported by #new: or #at:[put:].  It's based on Welford's
>>>>> stable update.
>>>>>
>>>>> Of course this approach does NOT work for trimmed or Winsorised
>>>>> means or for medians or any kind of robust estimate of location.
>>>>>
>>>>> SequenceableCollection
>>>>> methods for: 'summarising'
>>>>>  runningMeans: width
>>>>>    |a m d|
>>>>>    a := Array new: self size - width + 1.
>>>>>    m := 0.
>>>>>    1 to: width do: [:i |
>>>>>      m := (self at: i) + m].
>>>>>    m := m / width.
>>>>>    d := 1.
>>>>>    a at: d put: m.
>>>>>    width + 1 to: self size do: [:i |
>>>>>      m := ((self at: i) - (self at: d)) / width + m.
>>>>>      d := d + 1.
>>>>>      a at: d put: m].
>>>>>    ^a
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>

> El 13 abr 2020, a las 11:00, Richard O'Keefe <[hidden email]> escribió:
>
> Concerning method categories:
> VIsualAge Smalltalk manages without them.  Of all the Smalltalk
> systems available to me, it's the only one where I don't enjoy using
> the browser.  It carves up the world of methods another way, which I
> find of little or no help.  That in no way detracts from it being a
> solid system fit for its intended uses.
>
> GNU Smalltalk uses <category: 'whatever'> pragmas to put methods into
> categories.
>
> Used consistently and well, method categories are not only a
> navigation aid, helping you to find methods you do not know the names
> of, but a helpful documentation aid.  For example, #runningMeans: is
> in the 'summarising' category.  In my Smalltalk, that means
> - it inspects every element of the collection
> - it does not change the collection
> - the result is somehow a summary or distillation of the elements
> Of course, to get the most from method categories, the method
> categories need to be documented, and you need to keep them as up to
> date as any other part of the source code.

>
> I can say that the discipline of trying to come up with meaningful
> categories and use them consistently has improved the quality of my
> code.
>
> On Mon, 13 Apr 2020 at 00:38, Cédrick Béler <[hidden email]> wrote:
>>
>> Fully agree on proper names.
>>
>> === I don’t know if this is because of free confinement time but I can keep on asking questions so I share some I hope will make sense (for the sake of discussion).
>>
>> For instance, I'm wondering if tests on conditions so as to raise proper exceptions is a good practice (for instance if the  width object does not make sense, like a float) #doesNotMakeSense btw would be a cool name for the « maybe » cases Richard was talking.
>>
>> Then I asked myself what are the drawbacks (especially on performance) on adding extra information to source code (a bit like longer variable names) ?
>>
>> There is the raw code and the sources code file that helps separating concerns. At least we don’t mind at all having longer literals (variables names, …).
>>
>> I cannot help is what about pragmas. I kind see roughly how they work. But is it possible to distinguish between runtime / source only pragmas (not sure I’m clear here but it seems to me that some are important for documentation purposes that are not needed at runtime) ?
>>
>> Also, I’ve never really liked method categories. I don’t really see how there are implemented but they don’t feel nice to me.
>> Could they be only pragmas ?
>>
>>
>>
>>
>>
>> Happy eater Sunday, stay all preserved (sad day for the game of life),
>>
>> Cédrick
>>
>>
>>
>>> Le 12 avr. 2020 à 14:22, Sven Van Caekenberghe <[hidden email]> a écrit :
>>>
>>>
>>>
>>>> On 12 Apr 2020, at 13:53, Cédrick Béler <[hidden email]> wrote:
>>>>
>>>> Beautiful ^^
>>>
>>> I also like it.
>>>
>>> But why the single letter variable names ? Why not:
>>>
>>> SequenceableCollection>>#runningMeans: width
>>> | means sum index |
>>> means := Array new: self size - width + 1.
>>> sum := 0.
>>> 1 to: width do: [ :each |
>>>   sum := sum + (self at: each) ].
>>> index := 1.
>>> means at: index put: sum / width.
>>> width + 1 to: self size do: [ :each |
>>>   sum := sum - (self at: index) + (self at: each).
>>>   index := index + 1.
>>>   means at: index put: sum / width ].
>>> ^ means
>>>
>>> A good comment, a correct initial bounds check and unit tests are also needed.
>>>
>>>> I would vote for inclusion in the base image ?
>>>> With your explanation as comments.
>>>>
>>>> I’ll play with it.
>>>>
>>>> Thanks
>>>> Cedrick
>>>>
>>>>> Le 12 avr. 2020 à 12:19, Richard O'Keefe <[hidden email]> a écrit :
>>>>>
>>>>> 
>>>>> I have coded and benchmarked 8 different running mean algorithms.
>>>>> In the presence of inexact numbers it is not as accurate as
>>>>> redoing the sums, but it's pretty close, and it's fast.
>>>>> If "width" is not an integer or is out of range, an error
>>>>> will be reported by #new: or #at:[put:].  It's based on Welford's
>>>>> stable update.
>>>>>
>>>>> Of course this approach does NOT work for trimmed or Winsorised
>>>>> means or for medians or any kind of robust estimate of location.
>>>>>
>>>>> SequenceableCollection
>>>>> methods for: 'summarising'
>>>>>  runningMeans: width
>>>>>    |a m d|
>>>>>    a := Array new: self size - width + 1.
>>>>>    m := 0.
>>>>>    1 to: width do: [:i |
>>>>>      m := (self at: i) + m].
>>>>>    m := m / width.
>>>>>    d := 1.
>>>>>    a at: d put: m.
>>>>>    width + 1 to: self size do: [:i |
>>>>>      m := ((self at: i) - (self at: d)) / width + m.
>>>>>      d := d + 1.
>>>>>      a at: d put: m].
>>>>>    ^a
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>

> El 13 abr 2020, a las 11:17, Cédrick Béler <[hidden email]> escribió:
>
>
>> Used consistently and well, method categories are not only a
>> navigation aid, helping you to find methods you do not know the names
>> of, but a helpful documentation aid.  For example, #runningMeans: is
>> in the 'summarising' category.  In my Smalltalk, that means
>> - it inspects every element of the collection
>> - it does not change the collection
>> - the result is somehow a summary or distillation of the elements
>
> Great. If only categories were more first class, we could store such information.

> Le 13 avr. 2020 à 12:03, Guillermo Polito <[hidden email]> a écrit :
>
>
>
>> El 13 abr 2020, a las 11:17, Cédrick Béler <[hidden email]> escribió:
>>
>>
>>> Used consistently and well, method categories are not only a
>>> navigation aid, helping you to find methods you do not know the names
>>> of, but a helpful documentation aid.  For example, #runningMeans: is
>>> in the 'summarising' category.  In my Smalltalk, that means
>>> - it inspects every element of the collection
>>> - it does not change the collection
>>> - the result is somehow a summary or distillation of the elements
>>
>> Great. If only categories were more first class, we could store such information.
>
> Haha just said the same in the other thread ^^.
> Sorry for the noise