> El 13 abr 2020, a las 11:00, Richard O'Keefe <rao...@gmail.com> 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.
It would be interesting if protocols had comments :)
>
> 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 <cdric...@gmail.com> 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 <s...@stfx.eu> a écrit :
>>>
>>>
>>>
>>>> On 12 Apr 2020, at 13:53, Cédrick Béler <cdric...@gmail.com> 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 <rao...@gmail.com> 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>
