#sum:, #detectSum:, #sumNumbers:

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
97 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

Re: #sum:, #detectSum:, #sumNumbers:

Sven Van Caekenberghe-2
Hi Henrik,

> On 25 Dec 2015, at 14:08, Henrik Nergaard <[hidden email]> wrote:
>
> Like this?
> http://smalltalkhub.com/#!/~Latsabben/NumIt

That is a cool take on a possible approach. Thanks for doing it, it makes it much easier to think about and discuss alternatives.

This inspired me to do something similar, but not quite. I am just thinking out loud by implementation. Here is my result:




There are some examples in the class comments.

Sven

> Best regards,
> Henrik
>
> -----Original Message-----
> From: Pharo-dev [mailto:[hidden email]] On Behalf Of stepharo
> Sent: Thursday, December 24, 2015 9:58 AM
> To: Pharo Development List <[hidden email]>
> Subject: Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers:
>
> Just a remark.
> I think that we discarded the proposition of having
>
> aCol arithmetic sum
>
> but I found it nice because there if was clear that you want to get back
> 0 for #().
>
> Stef
>


Collections-Operations-SvenVanCaekenberghe.1.mcz (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: #sum:, #detectSum:, #sumNumbers:

Guillermo Polito
I like these last.

Particularly because

 - it cleans the collection’s API
 - we can continue extending this idea to add parallelism, mutual exclusion...


> On 29 dic 2015, at 11:53 p.m., Sven Van Caekenberghe <[hidden email]> wrote:
>
> Hi Henrik,
>
>> On 25 Dec 2015, at 14:08, Henrik Nergaard <[hidden email]> wrote:
>>
>> Like this?
>> http://smalltalkhub.com/#!/~Latsabben/NumIt
>
> That is a cool take on a possible approach. Thanks for doing it, it makes it much easier to think about and discuss alternatives.
>
> This inspired me to do something similar, but not quite. I am just thinking out loud by implementation. Here is my result:
>
> <Collections-Operations-SvenVanCaekenberghe.1.mcz>
>
> There are some examples in the class comments.
>
> Sven
>
>> Best regards,
>> Henrik
>>
>> -----Original Message-----
>> From: Pharo-dev [mailto:[hidden email]] On Behalf Of stepharo
>> Sent: Thursday, December 24, 2015 9:58 AM
>> To: Pharo Development List <[hidden email]>
>> Subject: Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers:
>>
>> Just a remark.
>> I think that we discarded the proposition of having
>>
>> aCol arithmetic sum
>>
>> but I found it nice because there if was clear that you want to get back
>> 0 for #().
>>
>> Stef
>>
>


Reply | Threaded
Open this post in threaded view
|

Re: #sum:, #detectSum:, #sumNumbers:

Tudor Girba-2
In reply to this post by Sven Van Caekenberghe-2
Thank you, Sven!

I like this very much.

This would also mean that we could deprecate Collection>>#sum altogether :))

Cheers,
Doru


> On Dec 30, 2015, at 12:53 AM, Sven Van Caekenberghe <[hidden email]> wrote:
>
> Hi Henrik,
>
>> On 25 Dec 2015, at 14:08, Henrik Nergaard <[hidden email]> wrote:
>>
>> Like this?
>> http://smalltalkhub.com/#!/~Latsabben/NumIt
>
> That is a cool take on a possible approach. Thanks for doing it, it makes it much easier to think about and discuss alternatives.
>
> This inspired me to do something similar, but not quite. I am just thinking out loud by implementation. Here is my result:
>
> <Collections-Operations-SvenVanCaekenberghe.1.mcz>
>
> There are some examples in the class comments.
>
> Sven
>
>> Best regards,
>> Henrik
>>
>> -----Original Message-----
>> From: Pharo-dev [mailto:[hidden email]] On Behalf Of stepharo
>> Sent: Thursday, December 24, 2015 9:58 AM
>> To: Pharo Development List <[hidden email]>
>> Subject: Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers:
>>
>> Just a remark.
>> I think that we discarded the proposition of having
>>
>> aCol arithmetic sum
>>
>> but I found it nice because there if was clear that you want to get back
>> 0 for #().
>>
>> Stef
>>
>

--
www.tudorgirba.com
www.feenk.com

"Innovation comes in the least expected form.
That is, if it is expected, it already happened."


Reply | Threaded
Open this post in threaded view
|

Re: #sum:, #detectSum:, #sumNumbers:

Max Leske
Very, very cool Sven (and Henrik!)!

And it even works with exotic objects: { 1@2. 2@3 } numbers sum “—> (3@5)”

Could Collections-Arithmetic be integrated into the collections operations? Not really sure that’s a good idea, I just want to know.

Cheers,
Max

> On 04 Jan 2016, at 16:19, Tudor Girba <[hidden email]> wrote:
>
> Thank you, Sven!
>
> I like this very much.
>
> This would also mean that we could deprecate Collection>>#sum altogether :))
>
> Cheers,
> Doru
>
>
>> On Dec 30, 2015, at 12:53 AM, Sven Van Caekenberghe <[hidden email]> wrote:
>>
>> Hi Henrik,
>>
>>> On 25 Dec 2015, at 14:08, Henrik Nergaard <[hidden email]> wrote:
>>>
>>> Like this?
>>> http://smalltalkhub.com/#!/~Latsabben/NumIt
>>
>> That is a cool take on a possible approach. Thanks for doing it, it makes it much easier to think about and discuss alternatives.
>>
>> This inspired me to do something similar, but not quite. I am just thinking out loud by implementation. Here is my result:
>>
>> <Collections-Operations-SvenVanCaekenberghe.1.mcz>
>>
>> There are some examples in the class comments.
>>
>> Sven
>>
>>> Best regards,
>>> Henrik
>>>
>>> -----Original Message-----
>>> From: Pharo-dev [mailto:[hidden email]] On Behalf Of stepharo
>>> Sent: Thursday, December 24, 2015 9:58 AM
>>> To: Pharo Development List <[hidden email]>
>>> Subject: Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers:
>>>
>>> Just a remark.
>>> I think that we discarded the proposition of having
>>>
>>> aCol arithmetic sum
>>>
>>> but I found it nice because there if was clear that you want to get back
>>> 0 for #().
>>>
>>> Stef
>>>
>>
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "Innovation comes in the least expected form.
> That is, if it is expected, it already happened."
>
>


Reply | Threaded
Open this post in threaded view
|

Re: #sum:, #detectSum:, #sumNumbers:

Sven Van Caekenberghe-2
Thanks for the (positive) feedback.

My problem is: if you think this through, lots of things could change.

Consider that I added #magnitudes this would imply that sorting should move too, because you cannot assume the objects to be sortable (i.e. Magnitudes or conforming to that protocol).

Also, this would create a kind of parallel hierarchy, with more type information. It feels like a simple single inheritance hierarchy cannot cover all combinations (for example, being sequenceable and being numbers, as opposed to being just a collection of numbers).

Sorting an unordered collection is also different from sorting an ordered one (this last one could keep its type, or even be sorted in place).

So maybe this is a can of worms. I am all for dynamic typing, not for trying to add some (weak) for of static typing.

> On 07 Jan 2016, at 13:14, Max Leske <[hidden email]> wrote:
>
> Very, very cool Sven (and Henrik!)!
>
> And it even works with exotic objects: { 1@2. 2@3 } numbers sum “—> (3@5)”
>
> Could Collections-Arithmetic be integrated into the collections operations? Not really sure that’s a good idea, I just want to know.
>
> Cheers,
> Max
>
>> On 04 Jan 2016, at 16:19, Tudor Girba <[hidden email]> wrote:
>>
>> Thank you, Sven!
>>
>> I like this very much.
>>
>> This would also mean that we could deprecate Collection>>#sum altogether :))
>>
>> Cheers,
>> Doru
>>
>>
>>> On Dec 30, 2015, at 12:53 AM, Sven Van Caekenberghe <[hidden email]> wrote:
>>>
>>> Hi Henrik,
>>>
>>>> On 25 Dec 2015, at 14:08, Henrik Nergaard <[hidden email]> wrote:
>>>>
>>>> Like this?
>>>> http://smalltalkhub.com/#!/~Latsabben/NumIt
>>>
>>> That is a cool take on a possible approach. Thanks for doing it, it makes it much easier to think about and discuss alternatives.
>>>
>>> This inspired me to do something similar, but not quite. I am just thinking out loud by implementation. Here is my result:
>>>
>>> <Collections-Operations-SvenVanCaekenberghe.1.mcz>
>>>
>>> There are some examples in the class comments.
>>>
>>> Sven
>>>
>>>> Best regards,
>>>> Henrik
>>>>
>>>> -----Original Message-----
>>>> From: Pharo-dev [mailto:[hidden email]] On Behalf Of stepharo
>>>> Sent: Thursday, December 24, 2015 9:58 AM
>>>> To: Pharo Development List <[hidden email]>
>>>> Subject: Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers:
>>>>
>>>> Just a remark.
>>>> I think that we discarded the proposition of having
>>>>
>>>> aCol arithmetic sum
>>>>
>>>> but I found it nice because there if was clear that you want to get back
>>>> 0 for #().
>>>>
>>>> Stef
>>>>
>>>
>>
>> --
>> www.tudorgirba.com
>> www.feenk.com
>>
>> "Innovation comes in the least expected form.
>> That is, if it is expected, it already happened."
>>
>>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: #sum:, #detectSum:, #sumNumbers:

Denis Kudriashov
In reply to this post by Max Leske

2016-01-07 13:14 GMT+01:00 Max Leske <[hidden email]>:
Very, very cool Sven (and Henrik!)!

And it even works with exotic objects: { 1@2. 2@3 } numbers sum “—> (3@5)”

I really not understand how it helps with original problem. There was example with colors sum which was stop people to allow sum on empty collection. How extra message solve it?
Reply | Threaded
Open this post in threaded view
|

Re: #sum:, #detectSum:, #sumNumbers:

Ben Coman
In reply to this post by Guillermo Polito
On Mon, Jan 4, 2016 at 10:55 PM, Guillermo Polito
<[hidden email]> wrote:
> I like these last.
>
> Particularly because
>
>  - it cleans the collection’s API
>  - we can continue extending this idea to add parallelism, mutual exclusion...

I don't understand the second point.

>
>
>> On 29 dic 2015, at 11:53 p.m., Sven Van Caekenberghe <[hidden email]> wrote:
>>
>> Hi Henrik,
>>
>>> On 25 Dec 2015, at 14:08, Henrik Nergaard <[hidden email]> wrote:
>>>
>>> Like this?
>>> http://smalltalkhub.com/#!/~Latsabben/NumIt
>>
>> That is a cool take on a possible approach. Thanks for doing it, it makes it much easier to think about and discuss alternatives.
>>
>> This inspired me to do something similar, but not quite. I am just thinking out loud by implementation. Here is my result:
>>
>> <Collections-Operations-SvenVanCaekenberghe.1.mcz>

Interesting to great enthusiasm from several people.  Looks like I'm
in the minority but I'm wary of this.  It seems like
over-intellectualized design.  I'll need to remember whether to send
#magnitude or #numbers before an operation and which matches up with
which operations.  This seems harder for newcomers.  Are there any
other programming languages that do it this way?

>>
>> There are some examples in the class comments.

Class comment says CollectionOperations is "a class that offers
extended API to operate on collections assumed to contain objects of a
certain type."

>>1. CollectionOperations
>>2.   OperationsOnMagnitudes
>>3.     OperationsOnNumbers
>>4.        OperationsOnSequenceableNumbers

So 2 & 3 refer to the elements of the collection, so 4 makes me wonder
what elements are sequence-able numbers?   So 4 breaks the pattern to
refer to the type of collection not just the type of element.

Why is #average defined for OperationsOnNumbers rather than
OperationsOnMagnitudes? If I have a collection of magnitudes like Time
"17:28 . 17:29 . 17:31 . 17:32" or Duration "4 minutes . 6 minutes"
I would expect to be able to get 17:30 and 5 minutes as the respective
averages.
But then it doesn't make sense to average other magnitudes like
Character, so where does that leave us?

Also I'd like to sum Durations but its not defined for OperationsOnMagnitudes.

I guess I fear there is hidden complexity for little gain.   Maybe
those that like the idea can collaborate on a package they use on
their own projects to work out the kinks.

cheers -ben

>>
>> Sven
>>
>>> Best regards,
>>> Henrik
>>>
>>> -----Original Message-----
>>> From: Pharo-dev [mailto:[hidden email]] On Behalf Of stepharo
>>> Sent: Thursday, December 24, 2015 9:58 AM
>>> To: Pharo Development List <[hidden email]>
>>> Subject: Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers:
>>>
>>> Just a remark.
>>> I think that we discarded the proposition of having
>>>
>>> aCol arithmetic sum
>>>
>>> but I found it nice because there if was clear that you want to get back
>>> 0 for #().
>>>
>>> Stef
>>>
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: #sum:, #detectSum:, #sumNumbers:

Sven Van Caekenberghe-2
In reply to this post by Denis Kudriashov

> On 07 Jan 2016, at 14:08, Denis Kudriashov <[hidden email]> wrote:
>
>
> 2016-01-07 13:14 GMT+01:00 Max Leske <[hidden email]>:
> Very, very cool Sven (and Henrik!)!
>
> And it even works with exotic objects: { 1@2. 2@3 } numbers sum “—> (3@5)”
>
> I really not understand how it helps with original problem. There was example with colors sum which was stop people to allow sum on empty collection. How extra message solve it?

(You should look at the code ;-)

The example is confusing and not really relevant (because the points are not numbers).

Basically, sending #numbers to a collection returns an object, called a 'collection operations' object (just a wrapper) that offers an interface to do more operations on the collection, with the additional assumption that it now contains (real) numbers.

#(1 2 3) numbers sum => 6
#() numbers sum => 0
#(1 2 3) numbers product => 6
#() numbers product => 1

#(1 2 3) asSet magnitudes max
#() asSet magnitudes maxIfEmpty: [ 100 ]

But again, the code was just me thinking out loud, inspired by what Henrik did, I am totally not sure it is a really good idea.

Sven


Reply | Threaded
Open this post in threaded view
|

Re: #sum:, #detectSum:, #sumNumbers:

Sven Van Caekenberghe-2
In reply to this post by Ben Coman

> On 07 Jan 2016, at 14:23, Ben Coman <[hidden email]> wrote:
>
> On Mon, Jan 4, 2016 at 10:55 PM, Guillermo Polito
> <[hidden email]> wrote:
>> I like these last.
>>
>> Particularly because
>>
>> - it cleans the collection’s API
>> - we can continue extending this idea to add parallelism, mutual exclusion...
>
> I don't understand the second point.

Wrapping an object in another to add behaviour is a standard technique (as opposed to adding the behaviour to the object itself). There can be several reasons for doing this. It is not necessarily or always a good idea either (for example, extension protocols are nice too).

>>> On 29 dic 2015, at 11:53 p.m., Sven Van Caekenberghe <[hidden email]> wrote:
>>>
>>> Hi Henrik,
>>>
>>>> On 25 Dec 2015, at 14:08, Henrik Nergaard <[hidden email]> wrote:
>>>>
>>>> Like this?
>>>> http://smalltalkhub.com/#!/~Latsabben/NumIt
>>>
>>> That is a cool take on a possible approach. Thanks for doing it, it makes it much easier to think about and discuss alternatives.
>>>
>>> This inspired me to do something similar, but not quite. I am just thinking out loud by implementation. Here is my result:
>>>
>>> <Collections-Operations-SvenVanCaekenberghe.1.mcz>
>
> Interesting to great enthusiasm from several people.  Looks like I'm
> in the minority but I'm wary of this.  It seems like
> over-intellectualized design.

Yes, maybe ;-)

> I'll need to remember whether to send
> #magnitude or #numbers before an operation and which matches up with
> which operations.  This seems harder for newcomers.  

#(1 2 foo true false) sum => ?
#() sum => ?
{ window1. window2. window3 } max => ?

> Are there any other programming languages that do it this way?

There are not so many fully dynamic languages with non-homogeneous collections. Most languages have static typing and generic types (both are not what we want). But I would love to see how comparable languages solve this 'problem'.

Most language won't allow (or don't define) operations on collections that could fail because of the fact that they contain the wrong objects.

Having said that, I am not saying that I want to move away from our flexibility/simplicity !

>>>
>>> There are some examples in the class comments.
>
> Class comment says CollectionOperations is "a class that offers
> extended API to operate on collections assumed to contain objects of a
> certain type."
>
>>> 1. CollectionOperations
>>> 2.   OperationsOnMagnitudes
>>> 3.     OperationsOnNumbers
>>> 4.        OperationsOnSequenceableNumbers
>
> So 2 & 3 refer to the elements of the collection, so 4 makes me wonder
> what elements are sequence-able numbers?   So 4 breaks the pattern to
> refer to the type of collection not just the type of element.

Yes, that is a problem, it feels wrong. There are several dimensions that cannot be captured in one simple hierarchy.

> Why is #average defined for OperationsOnNumbers rather than
> OperationsOnMagnitudes? If I have a collection of magnitudes like Time
> "17:28 . 17:29 . 17:31 . 17:32" or Duration "4 minutes . 6 minutes"
> I would expect to be able to get 17:30 and 5 minutes as the respective
> averages.
> But then it doesn't make sense to average other magnitudes like
> Character, so where does that leave us?

You are wrong, a Magnitude is only comparable, it does not mean it can do arithmetic. You need arithmetic to compute average.

In this case, you could use #numbers to indicate that you see your objects as compatible with that (and the time objects mostly are).

But summing an empty collection of Durations, you would probably want Duration zero to be the result, and then we are back to our original problem ;-)

> Also I'd like to sum Durations but its not defined for OperationsOnMagnitudes.
>
> I guess I fear there is hidden complexity for little gain.   Maybe
> those that like the idea can collaborate on a package they use on
> their own projects to work out the kinks.
>
> cheers -ben
>
>>>
>>> Sven
>>>
>>>> Best regards,
>>>> Henrik
>>>>
>>>> -----Original Message-----
>>>> From: Pharo-dev [mailto:[hidden email]] On Behalf Of stepharo
>>>> Sent: Thursday, December 24, 2015 9:58 AM
>>>> To: Pharo Development List <[hidden email]>
>>>> Subject: Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers:
>>>>
>>>> Just a remark.
>>>> I think that we discarded the proposition of having
>>>>
>>>> aCol arithmetic sum
>>>>
>>>> but I found it nice because there if was clear that you want to get back
>>>> 0 for #().
>>>>
>>>> Stef


Reply | Threaded
Open this post in threaded view
|

Re: #sum:, #detectSum:, #sumNumbers:

Denis Kudriashov
In reply to this post by Sven Van Caekenberghe-2

2016-01-07 14:24 GMT+01:00 Sven Van Caekenberghe <[hidden email]>:
> Very, very cool Sven (and Henrik!)!
>
> And it even works with exotic objects: { 1@2. 2@3 } numbers sum “—> (3@5)”
>
> I really not understand how it helps with original problem. There was example with colors sum which was stop people to allow sum on empty collection. How extra message solve it?

(You should look at the code ;-)

The example is confusing and not really relevant (because the points are not numbers).

Basically, sending #numbers to a collection returns an object, called a 'collection operations' object (just a wrapper) that offers an interface to do more operations on the collection, with the additional assumption that it now contains (real) numbers.

#(1 2 3) numbers sum => 6
#() numbers sum => 0
#(1 2 3) numbers product => 6
#() numbers product => 1

#(1 2 3) asSet magnitudes max
#() asSet magnitudes maxIfEmpty: [ 100 ]

But again, the code was just me thinking out loud, inspired by what Henrik did, I am totally not sure it is a really good idea.

Ok. I see it. And I like It.

Reply | Threaded
Open this post in threaded view
|

Re: #sum:, #detectSum:, #sumNumbers:

Ben Coman
In reply to this post by Sven Van Caekenberghe-2
On Thu, Jan 7, 2016 at 9:40 PM, Sven Van Caekenberghe <[hidden email]> wrote:

>
>> On 07 Jan 2016, at 14:23, Ben Coman <[hidden email]> wrote:
>>
>> On Mon, Jan 4, 2016 at 10:55 PM, Guillermo Polito
>> <[hidden email]> wrote:
>>> I like these last.
>>>
>>> Particularly because
>>>
>>> - it cleans the collection’s API
>>> - we can continue extending this idea to add parallelism, mutual exclusion...
>>
>> I don't understand the second point.
>
> Wrapping an object in another to add behaviour is a standard technique (as opposed to adding the behaviour to the object itself). There can be several reasons for doing this. It is not necessarily or always a good idea either (for example, extension protocols are nice too).

> "standard technique"

Does it have a pattern name?, that I could look up to learn more (btw
I have Design Patterns Smalltalk Companion - but its hard to remember
them without using them in practice.) ?

cheers -ben

>
>>>> On 29 dic 2015, at 11:53 p.m., Sven Van Caekenberghe <[hidden email]> wrote:
>>>>
>>>> Hi Henrik,
>>>>
>>>>> On 25 Dec 2015, at 14:08, Henrik Nergaard <[hidden email]> wrote:
>>>>>
>>>>> Like this?
>>>>> http://smalltalkhub.com/#!/~Latsabben/NumIt
>>>>
>>>> That is a cool take on a possible approach. Thanks for doing it, it makes it much easier to think about and discuss alternatives.
>>>>
>>>> This inspired me to do something similar, but not quite. I am just thinking out loud by implementation. Here is my result:
>>>>
>>>> <Collections-Operations-SvenVanCaekenberghe.1.mcz>
>>
>> Interesting to great enthusiasm from several people.  Looks like I'm
>> in the minority but I'm wary of this.  It seems like
>> over-intellectualized design.
>
> Yes, maybe ;-)
>
>> I'll need to remember whether to send
>> #magnitude or #numbers before an operation and which matches up with
>> which operations.  This seems harder for newcomers.
>
> #(1 2 foo true false) sum => ?
> #() sum => ?
> { window1. window2. window3 } max => ?
>
>> Are there any other programming languages that do it this way?
>
> There are not so many fully dynamic languages with non-homogeneous collections. Most languages have static typing and generic types (both are not what we want). But I would love to see how comparable languages solve this 'problem'.
>
> Most language won't allow (or don't define) operations on collections that could fail because of the fact that they contain the wrong objects.
>
> Having said that, I am not saying that I want to move away from our flexibility/simplicity !
>
>>>>
>>>> There are some examples in the class comments.
>>
>> Class comment says CollectionOperations is "a class that offers
>> extended API to operate on collections assumed to contain objects of a
>> certain type."
>>
>>>> 1. CollectionOperations
>>>> 2.   OperationsOnMagnitudes
>>>> 3.     OperationsOnNumbers
>>>> 4.        OperationsOnSequenceableNumbers
>>
>> So 2 & 3 refer to the elements of the collection, so 4 makes me wonder
>> what elements are sequence-able numbers?   So 4 breaks the pattern to
>> refer to the type of collection not just the type of element.
>
> Yes, that is a problem, it feels wrong. There are several dimensions that cannot be captured in one simple hierarchy.
>
>> Why is #average defined for OperationsOnNumbers rather than
>> OperationsOnMagnitudes? If I have a collection of magnitudes like Time
>> "17:28 . 17:29 . 17:31 . 17:32" or Duration "4 minutes . 6 minutes"
>> I would expect to be able to get 17:30 and 5 minutes as the respective
>> averages.
>> But then it doesn't make sense to average other magnitudes like
>> Character, so where does that leave us?
>
> You are wrong, a Magnitude is only comparable, it does not mean it can do arithmetic. You need arithmetic to compute average.
>
> In this case, you could use #numbers to indicate that you see your objects as compatible with that (and the time objects mostly are).
>
> But summing an empty collection of Durations, you would probably want Duration zero to be the result, and then we are back to our original problem ;-)
>
>> Also I'd like to sum Durations but its not defined for OperationsOnMagnitudes.
>>
>> I guess I fear there is hidden complexity for little gain.   Maybe
>> those that like the idea can collaborate on a package they use on
>> their own projects to work out the kinks.
>>
>> cheers -ben
>>
>>>>
>>>> Sven
>>>>
>>>>> Best regards,
>>>>> Henrik
>>>>>
>>>>> -----Original Message-----
>>>>> From: Pharo-dev [mailto:[hidden email]] On Behalf Of stepharo
>>>>> Sent: Thursday, December 24, 2015 9:58 AM
>>>>> To: Pharo Development List <[hidden email]>
>>>>> Subject: Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers:
>>>>>
>>>>> Just a remark.
>>>>> I think that we discarded the proposition of having
>>>>>
>>>>> aCol arithmetic sum
>>>>>
>>>>> but I found it nice because there if was clear that you want to get back
>>>>> 0 for #().
>>>>>
>>>>> Stef
>
>

Reply | Threaded
Open this post in threaded view
|

Re: #sum:, #detectSum:, #sumNumbers:

Nicolai Hess-3-2


2016-01-07 16:31 GMT+01:00 Ben Coman <[hidden email]>:
On Thu, Jan 7, 2016 at 9:40 PM, Sven Van Caekenberghe <[hidden email]> wrote:
>
>> On 07 Jan 2016, at 14:23, Ben Coman <[hidden email]> wrote:
>>
>> On Mon, Jan 4, 2016 at 10:55 PM, Guillermo Polito
>> <[hidden email]> wrote:
>>> I like these last.
>>>
>>> Particularly because
>>>
>>> - it cleans the collection’s API
>>> - we can continue extending this idea to add parallelism, mutual exclusion...
>>
>> I don't understand the second point.
>
> Wrapping an object in another to add behaviour is a standard technique (as opposed to adding the behaviour to the object itself). There can be several reasons for doing this. It is not necessarily or always a good idea either (for example, extension protocols are nice too).

> "standard technique"

Does it have a pattern name?, that I could look up to learn more (btw
I have Design Patterns Smalltalk Companion - but its hard to remember
them without using them in practice.) ?

 

cheers -ben

>
>>>> On 29 dic 2015, at 11:53 p.m., Sven Van Caekenberghe <[hidden email]> wrote:
>>>>
>>>> Hi Henrik,
>>>>
>>>>> On 25 Dec 2015, at 14:08, Henrik Nergaard <[hidden email]> wrote:
>>>>>
>>>>> Like this?
>>>>> http://smalltalkhub.com/#!/~Latsabben/NumIt
>>>>
>>>> That is a cool take on a possible approach. Thanks for doing it, it makes it much easier to think about and discuss alternatives.
>>>>
>>>> This inspired me to do something similar, but not quite. I am just thinking out loud by implementation. Here is my result:
>>>>
>>>> <Collections-Operations-SvenVanCaekenberghe.1.mcz>
>>
>> Interesting to great enthusiasm from several people.  Looks like I'm
>> in the minority but I'm wary of this.  It seems like
>> over-intellectualized design.
>
> Yes, maybe ;-)
>
>> I'll need to remember whether to send
>> #magnitude or #numbers before an operation and which matches up with
>> which operations.  This seems harder for newcomers.
>
> #(1 2 foo true false) sum => ?
> #() sum => ?
> { window1. window2. window3 } max => ?
>
>> Are there any other programming languages that do it this way?
>
> There are not so many fully dynamic languages with non-homogeneous collections. Most languages have static typing and generic types (both are not what we want). But I would love to see how comparable languages solve this 'problem'.
>
> Most language won't allow (or don't define) operations on collections that could fail because of the fact that they contain the wrong objects.
>
> Having said that, I am not saying that I want to move away from our flexibility/simplicity !
>
>>>>
>>>> There are some examples in the class comments.
>>
>> Class comment says CollectionOperations is "a class that offers
>> extended API to operate on collections assumed to contain objects of a
>> certain type."
>>
>>>> 1. CollectionOperations
>>>> 2.   OperationsOnMagnitudes
>>>> 3.     OperationsOnNumbers
>>>> 4.        OperationsOnSequenceableNumbers
>>
>> So 2 & 3 refer to the elements of the collection, so 4 makes me wonder
>> what elements are sequence-able numbers?   So 4 breaks the pattern to
>> refer to the type of collection not just the type of element.
>
> Yes, that is a problem, it feels wrong. There are several dimensions that cannot be captured in one simple hierarchy.
>
>> Why is #average defined for OperationsOnNumbers rather than
>> OperationsOnMagnitudes? If I have a collection of magnitudes like Time
>> "17:28 . 17:29 . 17:31 . 17:32" or Duration "4 minutes . 6 minutes"
>> I would expect to be able to get 17:30 and 5 minutes as the respective
>> averages.
>> But then it doesn't make sense to average other magnitudes like
>> Character, so where does that leave us?
>
> You are wrong, a Magnitude is only comparable, it does not mean it can do arithmetic. You need arithmetic to compute average.
>
> In this case, you could use #numbers to indicate that you see your objects as compatible with that (and the time objects mostly are).
>
> But summing an empty collection of Durations, you would probably want Duration zero to be the result, and then we are back to our original problem ;-)
>
>> Also I'd like to sum Durations but its not defined for OperationsOnMagnitudes.
>>
>> I guess I fear there is hidden complexity for little gain.   Maybe
>> those that like the idea can collaborate on a package they use on
>> their own projects to work out the kinks.
>>
>> cheers -ben
>>
>>>>
>>>> Sven
>>>>
>>>>> Best regards,
>>>>> Henrik
>>>>>
>>>>> -----Original Message-----
>>>>> From: Pharo-dev [mailto:[hidden email]] On Behalf Of stepharo
>>>>> Sent: Thursday, December 24, 2015 9:58 AM
>>>>> To: Pharo Development List <[hidden email]>
>>>>> Subject: Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers:
>>>>>
>>>>> Just a remark.
>>>>> I think that we discarded the proposition of having
>>>>>
>>>>> aCol arithmetic sum
>>>>>
>>>>> but I found it nice because there if was clear that you want to get back
>>>>> 0 for #().
>>>>>
>>>>> Stef
>
>


Reply | Threaded
Open this post in threaded view
|

Re: #sum:, #detectSum:, #sumNumbers:

Sven Van Caekenberghe-2
In reply to this post by Ben Coman

> On 07 Jan 2016, at 16:31, Ben Coman <[hidden email]> wrote:
>
> On Thu, Jan 7, 2016 at 9:40 PM, Sven Van Caekenberghe <[hidden email]> wrote:
>>
>>> On 07 Jan 2016, at 14:23, Ben Coman <[hidden email]> wrote:
>>>
>>> On Mon, Jan 4, 2016 at 10:55 PM, Guillermo Polito
>>> <[hidden email]> wrote:
>>>> I like these last.
>>>>
>>>> Particularly because
>>>>
>>>> - it cleans the collection’s API
>>>> - we can continue extending this idea to add parallelism, mutual exclusion...
>>>
>>> I don't understand the second point.
>>
>> Wrapping an object in another to add behaviour is a standard technique (as opposed to adding the behaviour to the object itself). There can be several reasons for doing this. It is not necessarily or always a good idea either (for example, extension protocols are nice too).
>
>> "standard technique"
>
> Does it have a pattern name?, that I could look up to learn more (btw
> I have Design Patterns Smalltalk Companion - but its hard to remember
> them without using them in practice.) ?

Something in the general direction of Proxy, Decorator and/or Adaptor ?

> cheers -ben
>
>>
>>>>> On 29 dic 2015, at 11:53 p.m., Sven Van Caekenberghe <[hidden email]> wrote:
>>>>>
>>>>> Hi Henrik,
>>>>>
>>>>>> On 25 Dec 2015, at 14:08, Henrik Nergaard <[hidden email]> wrote:
>>>>>>
>>>>>> Like this?
>>>>>> http://smalltalkhub.com/#!/~Latsabben/NumIt
>>>>>
>>>>> That is a cool take on a possible approach. Thanks for doing it, it makes it much easier to think about and discuss alternatives.
>>>>>
>>>>> This inspired me to do something similar, but not quite. I am just thinking out loud by implementation. Here is my result:
>>>>>
>>>>> <Collections-Operations-SvenVanCaekenberghe.1.mcz>
>>>
>>> Interesting to great enthusiasm from several people.  Looks like I'm
>>> in the minority but I'm wary of this.  It seems like
>>> over-intellectualized design.
>>
>> Yes, maybe ;-)
>>
>>> I'll need to remember whether to send
>>> #magnitude or #numbers before an operation and which matches up with
>>> which operations.  This seems harder for newcomers.
>>
>> #(1 2 foo true false) sum => ?
>> #() sum => ?
>> { window1. window2. window3 } max => ?
>>
>>> Are there any other programming languages that do it this way?
>>
>> There are not so many fully dynamic languages with non-homogeneous collections. Most languages have static typing and generic types (both are not what we want). But I would love to see how comparable languages solve this 'problem'.
>>
>> Most language won't allow (or don't define) operations on collections that could fail because of the fact that they contain the wrong objects.
>>
>> Having said that, I am not saying that I want to move away from our flexibility/simplicity !
>>
>>>>>
>>>>> There are some examples in the class comments.
>>>
>>> Class comment says CollectionOperations is "a class that offers
>>> extended API to operate on collections assumed to contain objects of a
>>> certain type."
>>>
>>>>> 1. CollectionOperations
>>>>> 2.   OperationsOnMagnitudes
>>>>> 3.     OperationsOnNumbers
>>>>> 4.        OperationsOnSequenceableNumbers
>>>
>>> So 2 & 3 refer to the elements of the collection, so 4 makes me wonder
>>> what elements are sequence-able numbers?   So 4 breaks the pattern to
>>> refer to the type of collection not just the type of element.
>>
>> Yes, that is a problem, it feels wrong. There are several dimensions that cannot be captured in one simple hierarchy.
>>
>>> Why is #average defined for OperationsOnNumbers rather than
>>> OperationsOnMagnitudes? If I have a collection of magnitudes like Time
>>> "17:28 . 17:29 . 17:31 . 17:32" or Duration "4 minutes . 6 minutes"
>>> I would expect to be able to get 17:30 and 5 minutes as the respective
>>> averages.
>>> But then it doesn't make sense to average other magnitudes like
>>> Character, so where does that leave us?
>>
>> You are wrong, a Magnitude is only comparable, it does not mean it can do arithmetic. You need arithmetic to compute average.
>>
>> In this case, you could use #numbers to indicate that you see your objects as compatible with that (and the time objects mostly are).
>>
>> But summing an empty collection of Durations, you would probably want Duration zero to be the result, and then we are back to our original problem ;-)
>>
>>> Also I'd like to sum Durations but its not defined for OperationsOnMagnitudes.
>>>
>>> I guess I fear there is hidden complexity for little gain.   Maybe
>>> those that like the idea can collaborate on a package they use on
>>> their own projects to work out the kinks.
>>>
>>> cheers -ben
>>>
>>>>>
>>>>> Sven
>>>>>
>>>>>> Best regards,
>>>>>> Henrik
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Pharo-dev [mailto:[hidden email]] On Behalf Of stepharo
>>>>>> Sent: Thursday, December 24, 2015 9:58 AM
>>>>>> To: Pharo Development List <[hidden email]>
>>>>>> Subject: Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers:
>>>>>>
>>>>>> Just a remark.
>>>>>> I think that we discarded the proposition of having
>>>>>>
>>>>>> aCol arithmetic sum
>>>>>>
>>>>>> but I found it nice because there if was clear that you want to get back
>>>>>> 0 for #().
>>>>>>
>>>>>> Stef


Reply | Threaded
Open this post in threaded view
|

Re: #sum:, #detectSum:, #sumNumbers:

Guillermo Polito

I'd say that it is not quite a proxy nor a decorator as their main characteristic is to maintain the api of its wrapee, and so be polymorphic and transparent. At least not the number example. The main reason of this wrappers are to augment the api. But i do not know if that has a name.

However, a wrapper implementing mutual exclusion could enter in the decorator category...

Le 7 janv. 2016 16:38, "Sven Van Caekenberghe" <[hidden email]> a écrit :

> On 07 Jan 2016, at 16:31, Ben Coman <[hidden email]> wrote:
>
> On Thu, Jan 7, 2016 at 9:40 PM, Sven Van Caekenberghe <[hidden email]> wrote:
>>
>>> On 07 Jan 2016, at 14:23, Ben Coman <[hidden email]> wrote:
>>>
>>> On Mon, Jan 4, 2016 at 10:55 PM, Guillermo Polito
>>> <[hidden email]> wrote:
>>>> I like these last.
>>>>
>>>> Particularly because
>>>>
>>>> - it cleans the collection’s API
>>>> - we can continue extending this idea to add parallelism, mutual exclusion...
>>>
>>> I don't understand the second point.
>>
>> Wrapping an object in another to add behaviour is a standard technique (as opposed to adding the behaviour to the object itself). There can be several reasons for doing this. It is not necessarily or always a good idea either (for example, extension protocols are nice too).
>
>> "standard technique"
>
> Does it have a pattern name?, that I could look up to learn more (btw
> I have Design Patterns Smalltalk Companion - but its hard to remember
> them without using them in practice.) ?

Something in the general direction of Proxy, Decorator and/or Adaptor ?

> cheers -ben
>
>>
>>>>> On 29 dic 2015, at 11:53 p.m., Sven Van Caekenberghe <[hidden email]> wrote:
>>>>>
>>>>> Hi Henrik,
>>>>>
>>>>>> On 25 Dec 2015, at 14:08, Henrik Nergaard <[hidden email]> wrote:
>>>>>>
>>>>>> Like this?
>>>>>> http://smalltalkhub.com/#!/~Latsabben/NumIt
>>>>>
>>>>> That is a cool take on a possible approach. Thanks for doing it, it makes it much easier to think about and discuss alternatives.
>>>>>
>>>>> This inspired me to do something similar, but not quite. I am just thinking out loud by implementation. Here is my result:
>>>>>
>>>>> <Collections-Operations-SvenVanCaekenberghe.1.mcz>
>>>
>>> Interesting to great enthusiasm from several people.  Looks like I'm
>>> in the minority but I'm wary of this.  It seems like
>>> over-intellectualized design.
>>
>> Yes, maybe ;-)
>>
>>> I'll need to remember whether to send
>>> #magnitude or #numbers before an operation and which matches up with
>>> which operations.  This seems harder for newcomers.
>>
>> #(1 2 foo true false) sum => ?
>> #() sum => ?
>> { window1. window2. window3 } max => ?
>>
>>> Are there any other programming languages that do it this way?
>>
>> There are not so many fully dynamic languages with non-homogeneous collections. Most languages have static typing and generic types (both are not what we want). But I would love to see how comparable languages solve this 'problem'.
>>
>> Most language won't allow (or don't define) operations on collections that could fail because of the fact that they contain the wrong objects.
>>
>> Having said that, I am not saying that I want to move away from our flexibility/simplicity !
>>
>>>>>
>>>>> There are some examples in the class comments.
>>>
>>> Class comment says CollectionOperations is "a class that offers
>>> extended API to operate on collections assumed to contain objects of a
>>> certain type."
>>>
>>>>> 1. CollectionOperations
>>>>> 2.   OperationsOnMagnitudes
>>>>> 3.     OperationsOnNumbers
>>>>> 4.        OperationsOnSequenceableNumbers
>>>
>>> So 2 & 3 refer to the elements of the collection, so 4 makes me wonder
>>> what elements are sequence-able numbers?   So 4 breaks the pattern to
>>> refer to the type of collection not just the type of element.
>>
>> Yes, that is a problem, it feels wrong. There are several dimensions that cannot be captured in one simple hierarchy.
>>
>>> Why is #average defined for OperationsOnNumbers rather than
>>> OperationsOnMagnitudes? If I have a collection of magnitudes like Time
>>> "17:28 . 17:29 . 17:31 . 17:32" or Duration "4 minutes . 6 minutes"
>>> I would expect to be able to get 17:30 and 5 minutes as the respective
>>> averages.
>>> But then it doesn't make sense to average other magnitudes like
>>> Character, so where does that leave us?
>>
>> You are wrong, a Magnitude is only comparable, it does not mean it can do arithmetic. You need arithmetic to compute average.
>>
>> In this case, you could use #numbers to indicate that you see your objects as compatible with that (and the time objects mostly are).
>>
>> But summing an empty collection of Durations, you would probably want Duration zero to be the result, and then we are back to our original problem ;-)
>>
>>> Also I'd like to sum Durations but its not defined for OperationsOnMagnitudes.
>>>
>>> I guess I fear there is hidden complexity for little gain.   Maybe
>>> those that like the idea can collaborate on a package they use on
>>> their own projects to work out the kinks.
>>>
>>> cheers -ben
>>>
>>>>>
>>>>> Sven
>>>>>
>>>>>> Best regards,
>>>>>> Henrik
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Pharo-dev [mailto:[hidden email]] On Behalf Of stepharo
>>>>>> Sent: Thursday, December 24, 2015 9:58 AM
>>>>>> To: Pharo Development List <[hidden email]>
>>>>>> Subject: Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers:
>>>>>>
>>>>>> Just a remark.
>>>>>> I think that we discarded the proposition of having
>>>>>>
>>>>>> aCol arithmetic sum
>>>>>>
>>>>>> but I found it nice because there if was clear that you want to get back
>>>>>> 0 for #().
>>>>>>
>>>>>> Stef


Reply | Threaded
Open this post in threaded view
|

Re: #sum:, #detectSum:, #sumNumbers:

stepharo
In reply to this post by Sven Van Caekenberghe-2
Sven

may be should do the following:
     - introduce the best solution (not using your and henrik decomposition)
     - continue to think about it.

I would like to see if Xtreams does not go in the same direction too.
But I do not have the code at hand to think about it.

Stef

Reply | Threaded
Open this post in threaded view
|

Re: #sum:, #detectSum:, #sumNumbers:

Sven Van Caekenberghe-2

> On 08 Jan 2016, at 21:15, stepharo <[hidden email]> wrote:
>
> Sven
>
> may be should do the following:
>    - introduce the best solution (not using your and henrik decomposition)
>    - continue to think about it.

There is no intermediary solution, we'll continue to think about it.

> I would like to see if Xtreams does not go in the same direction too. But I do not have the code at hand to think about it.

Xtreams does not solve the problem either, I think.

The key question is: can you write operations on objects, generic containers of element objects, that depend on the fact that the element objects are of a certain type (or protocol), but that might fail and make completely no sense for others.

Consider the 'data get/put' category on PositionalStream with operations like #int32 and #int32: - these assume that this are byte streams. But in my book, streams can be anything, colors, records, points, fonts, ...

> Stef


Reply | Threaded
Open this post in threaded view
|

Re: #sum:, #detectSum:, #sumNumbers:

Max Leske
Ok. So while the “decorator” approach looks fantastic it will obviously have its own drawbacks.

Discussing this on the mailing list is very tiering, so I suggest that this should be discussed during the next sprint or Pharo days. Since I will not be able to attend either one, can I ask one of you to take responsibility for this? Sven or Doru maybe?

Cheers,
Max

> On 11 Jan 2016, at 08:10, Sven Van Caekenberghe <[hidden email]> wrote:
>
>
>> On 08 Jan 2016, at 21:15, stepharo <[hidden email]> wrote:
>>
>> Sven
>>
>> may be should do the following:
>>   - introduce the best solution (not using your and henrik decomposition)
>>   - continue to think about it.
>
> There is no intermediary solution, we'll continue to think about it.
>
>> I would like to see if Xtreams does not go in the same direction too. But I do not have the code at hand to think about it.
>
> Xtreams does not solve the problem either, I think.
>
> The key question is: can you write operations on objects, generic containers of element objects, that depend on the fact that the element objects are of a certain type (or protocol), but that might fail and make completely no sense for others.
>
> Consider the 'data get/put' category on PositionalStream with operations like #int32 and #int32: - these assume that this are byte streams. But in my book, streams can be anything, colors, records, points, fonts, ...
>
>> Stef
>
>


12345