[Cuis-dev] Bag>>#sum:ifEmpty:

Wed Nov 2 23:09:05 PDT 2022

Hi Martin,
That’s very interesting. I guess this was not the best example, since not
being able to modify a collection while it’s iterating doesn’t really have
to do with the essence of the collections or their messages, but more with
a limitation of the implementation.
Is there a way to change existing collections to support modification while
iterating without loosing performance?

On Thu, 3 Nov 2022 at 12:44 Martin McClure <martin at hand2mouse.com> wrote:

> Hi Luciano,
>
> I agree that restricting #sum: to be used with a block that is a function
> is reasonable, and probably best.
>
> But I disagree about changing a collection while iterating it. I have
> often wanted a collection that could be modified while iterating it. And,
> given how much time I've spent writing stuff that has to work in a
> multi-threaded environment, I've probably implemented that sort of
> collection at least once. My idea of desirable semantics for this kind of
> collection are:
> 1) The iteration *will* include each element that is present throughout
> the iteration.
> 2) It is *unpredictable* whether any elements added or removed during the
> iteration are included in the iteration.
> 3) The same element (same being equal or identical, depending on the
> collection) will appear at most once in the iteration.
>
> There are a number of cases where this is useful.
>
> * The iterating thread may want to add or remove elements while it
> iterates.
> A queue is a simple example of this kind of collection, where the iterator
> is unconditionally removing elements as they're iterated, while some other
> entity may be concurrently adding elements. This can be generalized to
> conditional removal of elements that are iterated, or conditional adding of
> elements based on elements found.
>
> * Modification of the collection and iteration of the collection might
> happen in separate threads. There are times when a "more or less
> up-to-date" iteration of the contents is fine.
>
> Regards,
> -Martin
>
> On 11/2/22 21:57, Luciano Notarfrancesco via Cuis-dev wrote:
>
> Yes, the method assumes the block is a function (it maps one element to
> only one value). We talked about this here a couple of times. The
> Collection protocol is very “functional”, specially messages like
> #collect:, #select:, #detect:, etc, and using them with blocks that are
> functions is the most natural way to use them, and I don’t think we loose
> anything by making the assumption that the blocks for these messages are
> functions.
> Moreover, the whole point of Bag is to be able to efficiently store
> elements with lots of repetitions, possibly millions of repetitions that
> otherwise wouldn’t even fit in memory. If #sum: iterated over all the
> repetitions it would defeat the original purpose of Bag. And I argue that
> this is not necessary because no one would ever call #sum: with a block
> that is not a function, at least I never had the need to do that, and it
> feels unnatural to use #sum: in that way and I’d use #do: instead.
> If you think this assumption is strange, think about all the other
> assumptions that collections make. For example, you cannot change a
> collection while you’re iterating it. It would just feel wrong to change a
> collection while you iterate it, we don’t need to try to support that
> because who would do that?
>
>
> On Thu, 3 Nov 2022 at 03:12 Hernán Wilkinson <hernan.wilkinson at 10pines.com>
> wrote:
>
>> How does that optimization work?
>> Because I thought about evaluating the block and multiplying that for the
>> number of elements, but that makes sense if the block returns always the
>> same value por the same element, if it does not then it will not work...
>>
>>
>> On Wed, Nov 2, 2022 at 3:24 PM Juan Vuletich <juan at cuis.st> wrote:
>>
>>> On 11/1/2022 11:23 PM, Hernán Wilkinson via Cuis-dev wrote:
>>>
>>> yeap, the current implementation is not correct.
>>> Juan, attached is a change set that fixes it and another with the
>>> related tests.
>>>
>>> Cheers!
>>> Hernan.
>>>
>>> On Tue, Nov 1, 2022 at 3:39 AM Luciano Notarfrancesco <
>>> luchiano at gmail.com> wrote:
>>>
>>>> I’m afk right now so I cannot check, but it sounds like I made a
>>>> mistake. Of course it should be the value of aBlock at each element times
>>>> the number of occurrences.
>>>>
>>>> On Tue, 1 Nov 2022 at 07:33 Hernán Wilkinson <
>>>> hernan.wilkinson at 10pines.com> wrote:
>>>>
>>>>> Hi,
>>>>>  the implementation of Bag>>#sum: aBlock ifEmpty: emptyBlock does not
>>>>> use the parameter aBlock at all and assumes that each of the elements
>>>>> answers the message *
>>>>>  @Luciano Notarfrancesco <luchiano at gmail.com> the implementation is
>>>>> yours and it is very new? Is there a reason you did that way?
>>>>>
>>>>> Thanks
>>>>> Hernan
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> *Hernán Wilkinson Agile Software Development, Teaching & Coaching*
>>>>> *Phone: +54-011*-4893-2057
>>>>> *Twitter: @HernanWilkinson*
>>>>> *site: http://www.10Pines.com <http://www.10pines.com/>*
>>>>> Address: Alem 896, Floor 6, Buenos Aires, Argentina
>>>>>
>>>>
>>>
>>> --
>>>
>>> *Hernán Wilkinson Agile Software Development, Teaching & Coaching*
>>> *Phone: +54-011*-4893-2057
>>> *Twitter: @HernanWilkinson*
>>> *site: http://www.10Pines.com <http://www.10pines.com/>*
>>> Address: Alem 896, Floor 6, Buenos Aires, Argentina
>>>
>>>
>>> Hi Hernán,
>>>
>>> Your fix disables the optimization Luciano did. I chose to fix Luciano's
>>> code. Did the same for #product: (same bug). Integrated your tests, and
>>> added another one for #product:
>>>
>>> Thanks,
>>>
>>> --
>>> Juan Vuletichcuis.stgithub.com/jvuletichresearchgate.net/profile/Juan-Vuletichindependent.academia.edu/JuanVuletichpatents.justia.com/inventor/juan-manuel-vuletichlinkedin.com/in/juan-vuletich-75611b3twitter.com/JuanVuletich
>>>
>>>
>>
>> --
>>
>> *Hernán Wilkinson Agile Software Development, Teaching & Coaching*
>> *Phone: +54-011*-4893-2057
>> *Twitter: @HernanWilkinson*
>> *site: http://www.10Pines.com <http://www.10pines.com/>*
>> Address: Alem 896, Floor 6, Buenos Aires, Argentina
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20221103/c0d9f37c/attachment-0001.htm>