#sum:, #detectSum:, #sumNumbers:
Locked
12345
12345
Re: #sum:, #detectSum:, #sumNumbers:
 
|
Doru,
> On 01 Dec 2015, at 15:11, Tudor Girba <[hidden email]> wrote: > > Hi, > >> On Dec 1, 2015, at 12:52 PM, Sven Van Caekenberghe <[hidden email]> wrote: >> >> >>> On 01 Dec 2015, at 12:45, Stephan Eggermont <[hidden email]> wrote: >>> >>> On 01-12-15 11:46, Sven Van Caekenberghe wrote: >>>> The basic question for me is, what should >>>> >>>> #() sum >>>> >>>> return. Right now, it is an error, I would very much like that for this common case the result would be 0. There is a lot of power (easy of use) in a unary selector, we should not destroy that with semantics that force a test before using it. >>> >>> I like the error, it aligns with most of our collection protocol. >> >> I hate the error, a lot ;-) >> >>> It shows the need for #sum:ifEmpty: though >> >> Yes, as long as #() sum == 0 > > That won’t work :). Why ? Please explain. >> I want the simplest case to be simple, having a non-0 default is a special case IMHO > > That is why you have sumNumbers:. We could also add Collection>>sumNumbers. > > We had this discussion at length before Pharo 4, and this is when we agreed to add sumNumbers: and let sum: be generic (like the name says it should be) and not assume that it should work with Numbers. It is not about numbers or not, you are still using #+ in your generic case, that is numeric in my book. It is about the zero element and how to deal with an empty collection. The current solution, which was indeed recently added, leaves the problem of what to do with an empty collection. There is no general solution, you have to specify a zero element. But for most people in most cases that will be effectively 0, so lets make the unary #sum respect that. (And unary #sum will also work for non-empty non-zero based objects). The less common case can then use the longer message. > Cheers, > Doru > >> >>> Stephan >>> >>> >>> >> >> > > -- > www.tudorgirba.com > > "Speaking louder won't make the point worthier." |
Re: #sum:, #detectSum:, #sumNumbers:
|
|
In reply to this post by Uko2
Hi,
> On Dec 1, 2015, at 3:21 PM, Yuriy Tymchuk <[hidden email]> wrote: > >> >> On 01 Dec 2015, at 15:11, Tudor Girba <[hidden email]> wrote: >> >> Hi, >> >>> On Dec 1, 2015, at 12:52 PM, Sven Van Caekenberghe <[hidden email]> wrote: >>> >>> >>>> On 01 Dec 2015, at 12:45, Stephan Eggermont <[hidden email]> wrote: >>>> >>>> On 01-12-15 11:46, Sven Van Caekenberghe wrote: >>>>> The basic question for me is, what should >>>>> >>>>> #() sum >>>>> >>>>> return. Right now, it is an error, I would very much like that for this common case the result would be 0. There is a lot of power (easy of use) in a unary selector, we should not destroy that with semantics that force a test before using it. >>>> >>>> I like the error, it aligns with most of our collection protocol. >>> >>> I hate the error, a lot ;-) >>> >>>> It shows the need for #sum:ifEmpty: though >>> >>> Yes, as long as #() sum == 0 >> >> That won’t work :). > > But wouldn’t it be nice to have #sum:ifEmpty:? I think that this is a nice way to describe summing. Otherwise I have to do ifEmpty: [ something ] ifNotEmpty: [ :col | col sum: … ] Sure. That would be fine, and would leave the meaning of sum to work with non-numbers objects. But, of course, you can also use sumNumbers: which starts from 0 not from anyOne and you will need no ifEmpty:. Cheers, Doru > > Cheers. > Uko > >> >>> I want the simplest case to be simple, having a non-0 default is a special case IMHO >> >> That is why you have sumNumbers:. We could also add Collection>>sumNumbers. >> >> We had this discussion at length before Pharo 4, and this is when we agreed to add sumNumbers: and let sum: be generic (like the name says it should be) and not assume that it should work with Numbers. >> >> Cheers, >> Doru >> >>> >>>> Stephan >>>> >>>> >>>> >>> >>> >> >> -- >> www.tudorgirba.com >> >> "Speaking louder won't make the point worthier." -- www.tudorgirba.com "There are no old things, there are only old ways of looking at them." |
Re: #sum:, #detectSum:, #sumNumbers:
|
|
In reply to this post by Sven Van Caekenberghe-2
I don't want to be heretic (or too orthodox), but why not to delegate
this behavior to other class (an iterator maybe?). It's too tempting adding these convenience methods to Collection and/or subclasses, but anything that requires an explicit protocol of its elements is wrong, IMO. something like aCollection arithmetic sum: [...] or.... aCollection arithmetic avg. My two cents for this. Regards! Esteban A. Maringolo |
|
|
@Doru
You’re missing the point: #anyOne *fails* for empty collections. > On 01 Dec 2015, at 15:31, Esteban A. Maringolo <[hidden email]> wrote: > > I don't want to be heretic (or too orthodox), but why not to delegate > this behavior to other class (an iterator maybe?). > > It's too tempting adding these convenience methods to Collection > and/or subclasses, but anything that requires an explicit protocol of > its elements is wrong, IMO. > > something like aCollection arithmetic sum: [...] or.... aCollection > arithmetic avg. Interesting thought! > > My two cents for this. > > Regards! > > > Esteban A. Maringolo > |
|
|
In reply to this post by Sven Van Caekenberghe-2
On Tue, Dec 1, 2015 at 10:24 PM, Sven Van Caekenberghe <[hidden email]> wrote:
> Doru, > >> On 01 Dec 2015, at 15:11, Tudor Girba <[hidden email]> wrote: >> >> Hi, >> >>> On Dec 1, 2015, at 12:52 PM, Sven Van Caekenberghe <[hidden email]> wrote: >>> >>> >>>> On 01 Dec 2015, at 12:45, Stephan Eggermont <[hidden email]> wrote: >>>> >>>> On 01-12-15 11:46, Sven Van Caekenberghe wrote: >>>>> The basic question for me is, what should >>>>> >>>>> #() sum >>>>> >>>>> return. Right now, it is an error, I would very much like that for this common case the result would be 0. There is a lot of power (easy of use) in a unary selector, we should not destroy that with semantics that force a test before using it. >>>> >>>> I like the error, it aligns with most of our collection protocol. >>> >>> I hate the error, a lot ;-) >>> >>>> It shows the need for #sum:ifEmpty: though >>> >>> Yes, as long as #() sum == 0 >> >> That won’t work :). > > Why ? Please explain. > >>> I want the simplest case to be simple, having a non-0 default is a special case IMHO >> >> That is why you have sumNumbers:. We could also add Collection>>sumNumbers. >> >> We had this discussion at length before Pharo 4, and this is when we agreed to add sumNumbers: and let sum: be generic (like the name says it should be) and not assume that it should work with Numbers. > > It is not about numbers or not, you are still using #+ in your generic case, that is numeric in my book. It is about the zero element and how to deal with an empty collection. > > The current solution, which was indeed recently added, leaves the problem of what to do with an empty collection. There is no general solution, you have to specify a zero element. > > But for most people in most cases that will be effectively 0, so lets make the unary #sum respect that. (And unary #sum will also work for non-empty non-zero based objects). The less common case can then use the longer message. https://en.wikipedia.org/wiki/Empty_sum |
|
|
In reply to this post by Max Leske
Hmm.
On Tue, Dec 1, 2015 at 12:17 AM, Max Leske <[hidden email]> wrote: Hi guys, Interesting. On my machine (which is apparently really slow right now), I get: [ 100 timesRepeat: [ (1 to: 1000000) detectSum: [:x|x] ] ] timeToRun 104874 [ 100 timesRepeat: [ (1 to: 1000000) detectSumSwitch: [:x|x] ] ] timeToRun 44369 (this second one is where I add have switched the order - sum + nextValue - for speed. So, a little over twice as fast). If I change SmallInteger to be a bit smarter, I get: [ 100 timesRepeat: [ (1 to: 1000000) detectSum: [:x|x] ] ] timeToRun 45257 In other words just marginally slower than the optimized method above. The benefit here is that future folks won't have to remember which way to do their arithmetic to make things fast. Smarter + (in SmallInteger): + aNumber "Primitive. Add the receiver to the argument and answer with the result
if it is a SmallInteger. Fail if the argument or the result is not a
SmallInteger Essential No Lookup. See Object documentation whatIsAPrimitive." <primitive: 1> ^aNumber class = SmallInteger ifFalse: [aNumber + self] ifTrue: [super + aNumber] Of course, this wants to be thoroughly tested before use - certain additions may now work in ways not expected before (such as adding an array to a small integer - you may get odd results). Still... #sumNumbers: <snip> -cbc |
Re: #sum:, #detectSum:, #sumNumbers:
|
|
In reply to this post by Max Leske
Hi,
> On Dec 1, 2015, at 5:13 PM, Max Leske <[hidden email]> wrote: > > @Doru > You’re missing the point: #anyOne *fails* for empty collections. I am not missing the point at all. I am saying that if you want sum: to be generic, it cannot assume a specific Zero object. And sum: should be generic because of its name. >> On 01 Dec 2015, at 15:31, Esteban A. Maringolo <[hidden email]> wrote: >> >> I don't want to be heretic (or too orthodox), but why not to delegate >> this behavior to other class (an iterator maybe?). >> >> It's too tempting adding these convenience methods to Collection >> and/or subclasses, but anything that requires an explicit protocol of >> its elements is wrong, IMO. >> >> something like aCollection arithmetic sum: [...] or.... aCollection >> arithmetic avg. > > > Interesting thought! +100 Doru >> >> My two cents for this. >> >> Regards! >> >> >> Esteban A. Maringolo >> > > -- www.tudorgirba.com "Every thing has its own flow." |
Re: #sum:, #detectSum:, #sumNumbers:
|
|
In reply to this post by Sven Van Caekenberghe-2
Hi,
> On Dec 1, 2015, at 3:24 PM, Sven Van Caekenberghe <[hidden email]> wrote: > > Doru, > >> On 01 Dec 2015, at 15:11, Tudor Girba <[hidden email]> wrote: >> >> Hi, >> >>> On Dec 1, 2015, at 12:52 PM, Sven Van Caekenberghe <[hidden email]> wrote: >>> >>> >>>> On 01 Dec 2015, at 12:45, Stephan Eggermont <[hidden email]> wrote: >>>> >>>> On 01-12-15 11:46, Sven Van Caekenberghe wrote: >>>>> The basic question for me is, what should >>>>> >>>>> #() sum >>>>> >>>>> return. Right now, it is an error, I would very much like that for this common case the result would be 0. There is a lot of power (easy of use) in a unary selector, we should not destroy that with semantics that force a test before using it. >>>> >>>> I like the error, it aligns with most of our collection protocol. >>> >>> I hate the error, a lot ;-) >>> >>>> It shows the need for #sum:ifEmpty: though >>> >>> Yes, as long as #() sum == 0 >> >> That won’t work :). > > Why ? Please explain. > >>> I want the simplest case to be simple, having a non-0 default is a special case IMHO >> >> That is why you have sumNumbers:. We could also add Collection>>sumNumbers. >> >> We had this discussion at length before Pharo 4, and this is when we agreed to add sumNumbers: and let sum: be generic (like the name says it should be) and not assume that it should work with Numbers. > > It is not about numbers or not, you are still using #+ in your generic case, that is numeric in my book. It is about the zero element and how to deal with an empty collection. > > The current solution, which was indeed recently added, leaves the problem of what to do with an empty collection. There is no general solution, you have to specify a zero element. Exactly. > But for most people in most cases that will be effectively 0, so lets make the unary #sum respect that. (And unary #sum will also work for non-empty non-zero based objects). The less common case can then use the longer message. You said it correctly: “most” :). That is why, a generic meaning should be left generic and provide a solution that will work with “all” cases :). It’s a matter of choice, but sum: has a too generic meaning to have it confined to numbers. Cheers, Doru >> Cheers, >> Doru >> >>> >>>> Stephan >>>> >>>> >>>> >>> >>> >> >> -- >> www.tudorgirba.com >> >> "Speaking louder won't make the point worthier." > > -- www.tudorgirba.com "Next time you see your life passing by, say 'hi' and get to know her." |
|
|
In reply to this post by Ben Coman
Lovely little discussion which would be great for beginning OO programmers to see. The question of whether to return 0 for an empty collection is interesting. While other things can be summed, we tend to think of sums returning numbers. In that sense, 0 is a great default return. On the other hand, having a specific object for a generic sum function is problematic (+1). There is a real tension and that would be a great discussion for people to have. Either way, the need for sumIfEmpty: is obvious. Cheers, Jeff On Tue, Dec 1, 2015 at 11:19 AM Ben Coman <[hidden email]> wrote: On Tue, Dec 1, 2015 at 10:24 PM, Sven Van Caekenberghe <[hidden email]> wrote: |
Re: #sum:, #detectSum:, #sumNumbers:
|
|
In reply to this post by Tudor Girba-2
> On 01 Dec 2015, at 17:43, Tudor Girba <[hidden email]> wrote: > > Hi, > >> On Dec 1, 2015, at 3:24 PM, Sven Van Caekenberghe <[hidden email]> wrote: >> >> Doru, >> >>> On 01 Dec 2015, at 15:11, Tudor Girba <[hidden email]> wrote: >>> >>> Hi, >>> >>>> On Dec 1, 2015, at 12:52 PM, Sven Van Caekenberghe <[hidden email]> wrote: >>>> >>>> >>>>> On 01 Dec 2015, at 12:45, Stephan Eggermont <[hidden email]> wrote: >>>>> >>>>> On 01-12-15 11:46, Sven Van Caekenberghe wrote: >>>>>> The basic question for me is, what should >>>>>> >>>>>> #() sum >>>>>> >>>>>> return. Right now, it is an error, I would very much like that for this common case the result would be 0. There is a lot of power (easy of use) in a unary selector, we should not destroy that with semantics that force a test before using it. >>>>> >>>>> I like the error, it aligns with most of our collection protocol. >>>> >>>> I hate the error, a lot ;-) >>>> >>>>> It shows the need for #sum:ifEmpty: though >>>> >>>> Yes, as long as #() sum == 0 >>> >>> That won’t work :). >> >> Why ? Please explain. >> >>>> I want the simplest case to be simple, having a non-0 default is a special case IMHO >>> >>> That is why you have sumNumbers:. We could also add Collection>>sumNumbers. >>> >>> We had this discussion at length before Pharo 4, and this is when we agreed to add sumNumbers: and let sum: be generic (like the name says it should be) and not assume that it should work with Numbers. >> >> It is not about numbers or not, you are still using #+ in your generic case, that is numeric in my book. It is about the zero element and how to deal with an empty collection. >> >> The current solution, which was indeed recently added, leaves the problem of what to do with an empty collection. There is no general solution, you have to specify a zero element. > > Exactly. > >> But for most people in most cases that will be effectively 0, so lets make the unary #sum respect that. (And unary #sum will also work for non-empty non-zero based objects). The less common case can then use the longer message. > > You said it correctly: “most” :). That is why, a generic meaning should be left generic and provide a solution that will work with “all” cases :). > > It’s a matter of choice, but sum: has a too generic meaning to have it confined to numbers. I think we all mean the same thing and understand each other's point. But the first meaning of 'sum' in Wikipedia leads to https://en.wikipedia.org/wiki/Summation which talks about numbers. I studied partly Mathematics, so I know there are different numeric systems and abstractions. My point is: the common case is adding (simple) numbers, the special case is the more general one, hence the best selector, #sum, should work for the common case, including for the empty one. Consider also Ben's link: https://en.wikipedia.org/wiki/Empty_sum Hence my suggestion to change #sum to | sum sample | self isEmpty ifTrue: [ ^ 0 ]. sample := self anyOne. sum := self inject: sample into: [ :accum :each | accum + each ]. ^ sum - sample And the same for #sum: Note that the above *will* work for all like today, just not if they are empty. Now, of course we will need the ifEmpty: variants for what I consider the less common cases. Can I also remark that both #inject:into: and #fold: are perfectly fine for more involved cases. We have a lot of API ;-) > Cheers, > Doru > >>> Cheers, >>> Doru >>> >>>> >>>>> Stephan >>>>> >>>>> >>>>> >>>> >>>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Speaking louder won't make the point worthier." >> >> > > -- > www.tudorgirba.com > > "Next time you see your life passing by, say 'hi' and get to know her." |
|
|
Even though we haven’t been able to completely agree on the resolution, I feel we can agree that we need to change something. I’ve opened an issue and copied the messages from this thread into it for documentation.
https://pharo.fogbugz.com/f/cases/17174/Unify-sum-sum-sumNumbers-and-detectSum Cheers, Max > On 01 Dec 2015, at 18:41, Sven Van Caekenberghe <[hidden email]> wrote: > > >> On 01 Dec 2015, at 17:43, Tudor Girba <[hidden email]> wrote: >> >> Hi, >> >>> On Dec 1, 2015, at 3:24 PM, Sven Van Caekenberghe <[hidden email]> wrote: >>> >>> Doru, >>> >>>> On 01 Dec 2015, at 15:11, Tudor Girba <[hidden email]> wrote: >>>> >>>> Hi, >>>> >>>>> On Dec 1, 2015, at 12:52 PM, Sven Van Caekenberghe <[hidden email]> wrote: >>>>> >>>>> >>>>>> On 01 Dec 2015, at 12:45, Stephan Eggermont <[hidden email]> wrote: >>>>>> >>>>>> On 01-12-15 11:46, Sven Van Caekenberghe wrote: >>>>>>> The basic question for me is, what should >>>>>>> >>>>>>> #() sum >>>>>>> >>>>>>> return. Right now, it is an error, I would very much like that for this common case the result would be 0. There is a lot of power (easy of use) in a unary selector, we should not destroy that with semantics that force a test before using it. >>>>>> >>>>>> I like the error, it aligns with most of our collection protocol. >>>>> >>>>> I hate the error, a lot ;-) >>>>> >>>>>> It shows the need for #sum:ifEmpty: though >>>>> >>>>> Yes, as long as #() sum == 0 >>>> >>>> That won’t work :). >>> >>> Why ? Please explain. >>> >>>>> I want the simplest case to be simple, having a non-0 default is a special case IMHO >>>> >>>> That is why you have sumNumbers:. We could also add Collection>>sumNumbers. >>>> >>>> We had this discussion at length before Pharo 4, and this is when we agreed to add sumNumbers: and let sum: be generic (like the name says it should be) and not assume that it should work with Numbers. >>> >>> It is not about numbers or not, you are still using #+ in your generic case, that is numeric in my book. It is about the zero element and how to deal with an empty collection. >>> >>> The current solution, which was indeed recently added, leaves the problem of what to do with an empty collection. There is no general solution, you have to specify a zero element. >> >> Exactly. >> >>> But for most people in most cases that will be effectively 0, so lets make the unary #sum respect that. (And unary #sum will also work for non-empty non-zero based objects). The less common case can then use the longer message. >> >> You said it correctly: “most” :). That is why, a generic meaning should be left generic and provide a solution that will work with “all” cases :). >> >> It’s a matter of choice, but sum: has a too generic meaning to have it confined to numbers. > > I think we all mean the same thing and understand each other's point. > > But the first meaning of 'sum' in Wikipedia leads to https://en.wikipedia.org/wiki/Summation which talks about numbers. I studied partly Mathematics, so I know there are different numeric systems and abstractions. My point is: the common case is adding (simple) numbers, the special case is the more general one, hence the best selector, #sum, should work for the common case, including for the empty one. > > Consider also Ben's link: > > https://en.wikipedia.org/wiki/Empty_sum > > Hence my suggestion to change #sum to > > | sum sample | > self isEmpty ifTrue: [ ^ 0 ]. > sample := self anyOne. > sum := self inject: sample into: [ :accum :each | accum + each ]. > ^ sum - sample > > And the same for #sum: > > Note that the above *will* work for all like today, just not if they are empty. Now, of course we will need the ifEmpty: variants for what I consider the less common cases. > > Can I also remark that both #inject:into: and #fold: are perfectly fine for more involved cases. We have a lot of API ;-) > >> Cheers, >> Doru >> >>>> Cheers, >>>> Doru >>>> >>>>> >>>>>> Stephan >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "Speaking louder won't make the point worthier." >>> >>> >> >> -- >> www.tudorgirba.com >> >> "Next time you see your life passing by, say 'hi' and get to know her." > > |
|
|
In reply to this post by Tudor Girba-2
On Wed, Dec 2, 2015 at 12:38 AM, Tudor Girba <[hidden email]> wrote:
> Hi, > >> On Dec 1, 2015, at 5:13 PM, Max Leske <[hidden email]> wrote: >> >> @Doru >> You’re missing the point: #anyOne *fails* for empty collections. > > I am not missing the point at all. I am saying that if you want sum: to be generic, it cannot assume a specific Zero object. > > And sum: should be generic because of its name. I am missing understanding the other use cases. Can you describe further the generic nature of #sum & #sum: ? I would have thought by default they only applied to numbers. cheers -ben > >>> On 01 Dec 2015, at 15:31, Esteban A. Maringolo <[hidden email]> wrote: >>> >>> I don't want to be heretic (or too orthodox), but why not to delegate >>> this behavior to other class (an iterator maybe?). >>> >>> It's too tempting adding these convenience methods to Collection >>> and/or subclasses, but anything that requires an explicit protocol of >>> its elements is wrong, IMO. >>> >>> something like aCollection arithmetic sum: [...] or.... aCollection >>> arithmetic avg. >> >> >> Interesting thought! > > +100 > > Doru > >>> >>> My two cents for this. >>> >>> Regards! >>> >>> >>> Esteban A. Maringolo >>> >> >> > > -- > www.tudorgirba.com > > "Every thing has its own flow." > > > > > |
Re: #sum:, #detectSum:, #sumNumbers:
|
|
2015-12-02 15:03 GMT+01:00 Ben Coman <[hidden email]>: On Wed, Dec 2, 2015 at 12:38 AM, Tudor Girba <[hidden email]> wrote: sum can be applied to anything that supports #+, not only numbers sum: can be applied to any collection with a block that return some object that supports #+ therefore you can not assume 0 (<- a number) is a proper initial value therefore you *need* to work with #anyOne and as you can not assume a proper initial value, you can not assume a default value for empty collections -> it should throw an error. If you (the caller of the function) knows what to do with an empty collection you have to check, or call inject:into: directly, with a proper initial value.
|
Re: #sum:, #detectSum:, #sumNumbers:
|
|
> On 02 Dec 2015, at 15:21, Nicolai Hess <[hidden email]> wrote: > > > > 2015-12-02 15:03 GMT+01:00 Ben Coman <[hidden email]>: > On Wed, Dec 2, 2015 at 12:38 AM, Tudor Girba <[hidden email]> wrote: > > Hi, > > > >> On Dec 1, 2015, at 5:13 PM, Max Leske <[hidden email]> wrote: > >> > >> @Doru > >> You’re missing the point: #anyOne *fails* for empty collections. > > > > I am not missing the point at all. I am saying that if you want sum: to be generic, it cannot assume a specific Zero object. > > > > And sum: should be generic because of its name. > > I am missing understanding the other use cases. Can you describe > further the generic nature of #sum & #sum: ? I would have thought by > default they only applied to numbers. > > sum can be applied to anything that supports #+, not only numbers > sum: can be applied to any collection with a block that return some object that supports #+ > > therefore you can not assume 0 (<- a number) is a proper initial value therefore you *need* to work with #anyOne > and as you can not assume a proper initial value, you can not assume a default value for empty collections > -> it should throw an error. If you (the caller of the function) knows what to do with an empty collection you have > to check, or call inject:into: directly, with a proper initial value. I am sorry but I am getting really tired of this, you should read what is being said. I am not suggesting to stop using #anyOne because I like why it is there and what it can do. The change I want is what happens with an empty collection when using the simplest selector, #sum. I do not want to say to some collection of numbers #sumIfEmpty: [0], because summing numbers starting from zero is the most common case and everybody expects that, hence the unary selector fits. I want the less common cases to use the more complicated API, as in some collection of colors #sumIfEmpty: [ Color black ] In my book that is common sense API design. Doing that I do no take anything away, because today you already have to make sure the collection is not empty. The only change would be in the error behaviour. I think that is a reasonable price to pay. Instead of having #anyOne fail, it will say that #+ cannot add 0 to some object, and in a comment we can point to the alternative API. http://izquotes.com/quote/242740 right ? > cheers -ben > > > > >>> On 01 Dec 2015, at 15:31, Esteban A. Maringolo <[hidden email]> wrote: > >>> > >>> I don't want to be heretic (or too orthodox), but why not to delegate > >>> this behavior to other class (an iterator maybe?). > >>> > >>> It's too tempting adding these convenience methods to Collection > >>> and/or subclasses, but anything that requires an explicit protocol of > >>> its elements is wrong, IMO. > >>> > >>> something like aCollection arithmetic sum: [...] or.... aCollection > >>> arithmetic avg. > >> > >> > >> Interesting thought! > > > > +100 > > > > Doru > > > >>> > >>> My two cents for this. > >>> > >>> Regards! > >>> > >>> > >>> Esteban A. Maringolo > >>> > >> > >> > > > > -- > > www.tudorgirba.com > > > > "Every thing has its own flow." > > > > > > > > > > |
Re: #sum:, #detectSum:, #sumNumbers:
|
|
> On 02 Dec 2015, at 15:45, Sven Van Caekenberghe <[hidden email]> wrote: > > The only change would be in the error behaviour. I think that is a reasonable price to pay. Instead of having #anyOne fail, it will say that #+ cannot add 0 to some object, and in a comment we can point to the alternative API. Make that: instead of having #anyOne fail (which is pretty obscure) it will return 0 which will then probably fail. |
|
|
In reply to this post by Sven Van Caekenberghe-2
On Wed, Dec 2, 2015 at 10:45 PM, Sven Van Caekenberghe <[hidden email]> wrote:
> >> On 02 Dec 2015, at 15:21, Nicolai Hess <[hidden email]> wrote: >> >> >> >> 2015-12-02 15:03 GMT+01:00 Ben Coman <[hidden email]>: >> On Wed, Dec 2, 2015 at 12:38 AM, Tudor Girba <[hidden email]> wrote: >> > Hi, >> > >> >> On Dec 1, 2015, at 5:13 PM, Max Leske <[hidden email]> wrote: >> >> >> >> @Doru >> >> You’re missing the point: #anyOne *fails* for empty collections. >> > >> > I am not missing the point at all. I am saying that if you want sum: to be generic, it cannot assume a specific Zero object. >> > >> > And sum: should be generic because of its name. >> >> I am missing understanding the other use cases. Can you describe >> further the generic nature of #sum & #sum: ? I would have thought by >> default they only applied to numbers. >> >> sum can be applied to anything that supports #+, not only numbers >> sum: can be applied to any collection with a block that return some object that supports #+ To me this is a mis-application of polymorphism, that just because something responds to #+ it should be summable. We have overloaded the semantics of #+ to mean both numeric addition and concatenation/membership, but technically "summation" relates only to numeric addition. https://www.google.com.au/search?q=define+sum&oq=define+sum https://www.google.com.au/search?q=define+concatenate&oq=define+concatenate For example... * KMModifier implements #+ so what is the expected semantic of " { KMModifier shift . KMModifier meta} sum " ? To me this is more of a concatenation/join/union facility rather than numeric addition. (btw, that expression actually fails since KMModifier does not understand minus #- ) . * String implements #+ and " { '1' . '2' } sum " --> '3', so actually its doing numeric addition. However " { 'a' . 'b' } sum " produces an error. So actually there seem some existing problems with summing non-numerics. What examples work? * Trait classes implement both #+ and #- , but the semantic seems more to do with membership than numeric addition. I don't how how to produce an example of using #sum against traits. * Points are summable " { 2@2 . 3@3 } " --> 5@5. But then " 2@2 + 1 " --> 3@3 , so " {} sum " returning 0 would seem to not cause any error in this case. cheers -ben >> >> therefore you can not assume 0 (<- a number) is a proper initial value therefore you *need* to work with #anyOne >> and as you can not assume a proper initial value, you can not assume a default value for empty collections >> -> it should throw an error. If you (the caller of the function) knows what to do with an empty collection you have >> to check, or call inject:into: directly, with a proper initial value. > > I am sorry but I am getting really tired of this, you should read what is being said. > > I am not suggesting to stop using #anyOne because I like why it is there and what it can do. > > The change I want is what happens with an empty collection when using the simplest selector, #sum. > > I do not want to say to some collection of numbers #sumIfEmpty: [0], because summing numbers starting from zero is the most common case and everybody expects that, hence the unary selector fits. > > I want the less common cases to use the more complicated API, as in some collection of colors #sumIfEmpty: [ Color black ] > > In my book that is common sense API design. > > Doing that I do no take anything away, because today you already have to make sure the collection is not empty. > > The only change would be in the error behaviour. I think that is a reasonable price to pay. Instead of having #anyOne fail, it will say that #+ cannot add 0 to some object, and in a comment we can point to the alternative API. > > http://izquotes.com/quote/242740 right ? > >> cheers -ben >> >> > >> >>> On 01 Dec 2015, at 15:31, Esteban A. Maringolo <[hidden email]> wrote: >> >>> >> >>> I don't want to be heretic (or too orthodox), but why not to delegate >> >>> this behavior to other class (an iterator maybe?). >> >>> >> >>> It's too tempting adding these convenience methods to Collection >> >>> and/or subclasses, but anything that requires an explicit protocol of >> >>> its elements is wrong, IMO. >> >>> >> >>> something like aCollection arithmetic sum: [...] or.... aCollection >> >>> arithmetic avg. >> >> >> >> >> >> Interesting thought! >> > >> > +100 >> > >> > Doru >> > >> >>> >> >>> My two cents for this. >> >>> >> >>> Regards! >> >>> >> >>> >> >>> Esteban A. Maringolo >> >>> >> >> >> >> >> > >> > -- >> > www.tudorgirba.com >> > >> > "Every thing has its own flow." >> > >> > >> > >> > >> > > > |
|
|
<uncontrolled snipping>
On Thu, Dec 3, 2015 at 5:48 AM, Ben Coman <[hidden email]> wrote:
but points aren't commutative: 2@2 + 1 " = 3@3" 1 + 2@2 " = 3@2" Of course, 0 wouldn't be an issue, unless you wanted to access x or y! -cbc |
Re: #sum:, #detectSum:, #sumNumbers:
|
|
In reply to this post by Ben Coman
2015-12-03 14:48 GMT+01:00 Ben Coman <[hidden email]>: On Wed, Dec 2, 2015 at 10:45 PM, Sven Van Caekenberghe <[hidden email]> wrote: I didn't wanted to argue for or against any change. I just wanted to clarify that there are situations in which a generic sum/sum: that throws an error on empty collections and don't assume a null value makes sense.
do that change, I am not against it. Ben just asked for an example and I thought it would be helpful.
|
|
|
On Fri, Dec 4, 2015 at 4:23 AM, Nicolai Hess <[hidden email]> wrote:
> > > 2015-12-03 14:48 GMT+01:00 Ben Coman <[hidden email]>: >> >> On Wed, Dec 2, 2015 at 10:45 PM, Sven Van Caekenberghe <[hidden email]> >> wrote: >> > >> >> On 02 Dec 2015, at 15:21, Nicolai Hess <[hidden email]> wrote: >> >> >> >> >> >> >> >> 2015-12-02 15:03 GMT+01:00 Ben Coman <[hidden email]>: >> >> On Wed, Dec 2, 2015 at 12:38 AM, Tudor Girba <[hidden email]> >> >> wrote: >> >> > Hi, >> >> > >> >> >> On Dec 1, 2015, at 5:13 PM, Max Leske <[hidden email]> wrote: >> >> >> >> >> >> @Doru >> >> >> You’re missing the point: #anyOne *fails* for empty collections. >> >> > >> >> > I am not missing the point at all. I am saying that if you want sum: >> >> > to be generic, it cannot assume a specific Zero object. >> >> > >> >> > And sum: should be generic because of its name. >> >> >> >> I am missing understanding the other use cases. Can you describe >> >> further the generic nature of #sum & #sum: ? I would have thought by >> >> default they only applied to numbers. >> >> >> >> sum can be applied to anything that supports #+, not only numbers >> >> sum: can be applied to any collection with a block that return some >> >> object that supports #+ >> >> To me this is a mis-application of polymorphism, that just because >> something responds to #+ it should be summable. We have overloaded the >> semantics of #+ to mean both numeric addition and >> concatenation/membership, but technically "summation" relates only to >> numeric addition. > > > I didn't wanted to argue for or against any change. I just wanted to clarify > that there are situations in which a generic sum/sum: that throws an error > on empty collections and don't assume a null value makes sense. > > >> >> >> https://www.google.com.au/search?q=define+sum&oq=define+sum >> >> https://www.google.com.au/search?q=define+concatenate&oq=define+concatenate >> >> For example... >> >> * KMModifier implements #+ so what is the expected semantic of " { >> KMModifier shift . KMModifier meta} sum " ? >> To me this is more of a concatenation/join/union facility rather than >> numeric addition. (btw, that expression actually fails since >> KMModifier does not understand minus #- ) . >> >> * String implements #+ and " { '1' . '2' } sum " --> '3', so >> actually its doing numeric addition. However " { 'a' . 'b' } sum " >> produces an error. >> >> So actually there seem some existing problems with summing >> non-numerics. What examples work? >> >> * Trait classes implement both #+ and #- , but the semantic seems >> more to do with membership than numeric addition. I don't how how to >> produce an example of using #sum against traits. >> >> * Points are summable " { 2@2 . 3@3 } " --> 5@5. But then " 2@2 + >> 1 " --> 3@3 , so " {} sum " returning 0 would seem to not >> cause any error in this case. >> >> >> cheers -ben >> >> >> >> >> >> therefore you can not assume 0 (<- a number) is a proper initial value >> >> therefore you *need* to work with #anyOne >> >> and as you can not assume a proper initial value, you can not assume a >> >> default value for empty collections >> >> -> it should throw an error. If you (the caller of the function) knows >> >> what to do with an empty collection you have >> >> to check, or call inject:into: directly, with a proper initial value. >> > >> > I am sorry but I am getting really tired of this, you should read what >> > is being said. > > > do that change, I am not against it. Ben just asked for an example and I > thought it would be helpful. It was helpful :) It evolved my thinking. Now thinking further, I wonder how returning 0 will work with applications using units like Aconcagua, and if it would over-complicate things to do something like... Collection>>sum | sum sample | self isEmpty ifTrue: [ ^ ArithmeticZero ]. sample := self anyOne. sum := self inject: sample into: [ :accum :each | accum + each ]. ^ sum - sample ArithmeticZero class >> + anObject ^anObject cheers -ben > > >> >> > >> > I am not suggesting to stop using #anyOne because I like why it is there >> > and what it can do. >> > >> > The change I want is what happens with an empty collection when using >> > the simplest selector, #sum. >> > >> > I do not want to say to some collection of numbers #sumIfEmpty: [0], >> > because summing numbers starting from zero is the most common case and >> > everybody expects that, hence the unary selector fits. >> > >> > I want the less common cases to use the more complicated API, as in some >> > collection of colors #sumIfEmpty: [ Color black ] >> > >> > In my book that is common sense API design. >> > >> > Doing that I do no take anything away, because today you already have to >> > make sure the collection is not empty. >> > >> > The only change would be in the error behaviour. I think that is a >> > reasonable price to pay. Instead of having #anyOne fail, it will say that #+ >> > cannot add 0 to some object, and in a comment we can point to the >> > alternative API. > > > > >> >> > >> > http://izquotes.com/quote/242740 right ? >> > >> >> cheers -ben >> >> >> >> > >> >> >>> On 01 Dec 2015, at 15:31, Esteban A. Maringolo >> >> >>> <[hidden email]> wrote: >> >> >>> >> >> >>> I don't want to be heretic (or too orthodox), but why not to >> >> >>> delegate >> >> >>> this behavior to other class (an iterator maybe?). >> >> >>> >> >> >>> It's too tempting adding these convenience methods to Collection >> >> >>> and/or subclasses, but anything that requires an explicit protocol >> >> >>> of >> >> >>> its elements is wrong, IMO. >> >> >>> >> >> >>> something like aCollection arithmetic sum: [...] or.... aCollection >> >> >>> arithmetic avg. On Fri, Dec 4, 2015 at 3:26 AM, Chris Cunningham <[hidden email]> wrote: > <uncontrolled snipping> > > On Thu, Dec 3, 2015 at 5:48 AM, Ben Coman <[hidden email]> wrote: >> * Points are summable " { 2@2 . 3@3 } " --> 5@5. But then " 2@2 + >> 1 " --> 3@3 , so " {} sum " returning 0 would seem to not >> cause any error in this case. > > but points aren't commutative: > > 2@2 + 1 " = 3@3" > 1 + 2@2 " = 3@2" > > Of course, 0 wouldn't be an issue, unless you wanted to access x or y! |
|
|
In reply to this post by cbc
On Fri, Dec 4, 2015 at 3:26 AM, Chris Cunningham
<[hidden email]> wrote: > <uncontrolled snipping> > > On Thu, Dec 3, 2015 at 5:48 AM, Ben Coman <[hidden email]> wrote: >> >> >> >> * Points are summable " { 2@2 . 3@3 } " --> 5@5. But then " 2@2 + >> 1 " --> 3@3 , so " {} sum " returning 0 would seem to not >> cause any error in this case. >> >> >> cheers -ben > > > but points aren't commutative: > > 2@2 + 1 " = 3@3" > 1 + 2@2 " = 3@2" > > Of course, 0 wouldn't be an issue, unless you wanted to access x or y! > > -cbc whoops? 1 + (2@2) = 3@3 cheers -ben |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |