December 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers:

by Tudor Girba

Hi, > On Dec 1, 2015, at 3:21 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > >> >> On 01 Dec 2015, at 15:11, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> Hi, >> >>> On Dec 1, 2015, at 12:52 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>> >>>> On 01 Dec 2015, at 12:45, Stephan Eggermont <stephan(a)stack.nl> 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."

Dec. 1, 2015

Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers:

by Sven Van Caekenberghe

Doru, > On 01 Dec 2015, at 15:11, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > >> On Dec 1, 2015, at 12:52 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> >>> On 01 Dec 2015, at 12:45, Stephan Eggermont <stephan(a)stack.nl> 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."

Dec. 1, 2015

Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers:

by Yuriy Tymchuk

> On 01 Dec 2015, at 15:11, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > >> On Dec 1, 2015, at 12:52 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> >>> On 01 Dec 2015, at 12:45, Stephan Eggermont <stephan(a)stack.nl> 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: â¦ ] 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." > >

Dec. 1, 2015

Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers:

by Tudor Girba

Hi, > On Dec 1, 2015, at 12:52 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > >> On 01 Dec 2015, at 12:45, Stephan Eggermont <stephan(a)stack.nl> 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 :). > 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."

Dec. 1, 2015

Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers:

by Yuriy Tymchuk

#sum:ifEmpty: looks nice > On 01 Dec 2015, at 12:45, Stephan Eggermont <stephan(a)stack.nl> 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. > It shows the need for #sum:ifEmpty: though > > Stephan > > >

Dec. 1, 2015

Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers:

by Max Leske

Well, Iâm glad I've struck a nerve there :) I agree that signalling an exception isnât wrong, itâs just annoying because you have to do the check manually each time. I think I like #sum:ifEmpty:. When you look through the methods in Collection youâll see #sum, #sum: and #sum:ifEmpty together in one place and it will be clear how to use them. > On 01 Dec 2015, at 12:52, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > >> On 01 Dec 2015, at 12:45, Stephan Eggermont <stephan(a)stack.nl> 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 ;-) +1 > >> It shows the need for #sum:ifEmpty: though > > Yes, as long as #() sum == 0 +100 That allows for nice Smalltalk like âmyNumbers sum isZero â¦â. > > I want the simplest case to be simple, having a non-0 default is a special case IMHO > >> Stephan >> >> >> > >

Dec. 1, 2015

Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers:

by Sven Van Caekenberghe

> On 01 Dec 2015, at 12:45, Stephan Eggermont <stephan(a)stack.nl> 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 I want the simplest case to be simple, having a non-0 default is a special case IMHO > Stephan > > >

Dec. 1, 2015

Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers:

by Stephan Eggermont

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. It shows the need for #sum:ifEmpty: though Stephan

Dec. 1, 2015

Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers:

by Peter Uhnak

On 12/01, Thierry Goubier wrote: > 2015-12-01 11:46 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > > 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. > > > > Yes, this is just that a 0 value is returned for an empty collection, and, > if you're expecting a sum of Colors, then this is a bit strange. > > Returning an error on a sum for an empty collection is maybe an overall > cleaner concept > > Which can be expressed as: > > I prefer this code: > > aCollectionOfColors isEmpty > ifTrue: [ sumOfColors := aDefaultColor ] > ifFalse: [ sumOfColors := aCollectionOfColors sum ] > > To this code: > > sumOfColors := aCollectionOfColors sum. > sumOfColors = 0 > ifTrue: [ sumOfColors := aDefaultColor ] or sumOfColors := (aCollectionOfColors ifEmpty: [ {aDefaultColor} ]) sum. > > > > > > If we agree on that, we could change the #sum to > > > > | sum sample | > > self isEmpty ifTrue: [ ^ 0 ]. > > sample := self anyOne. > > sum := self inject: sample into: [ :accum :each | accum + each ]. > > ^ sum - sample > > > > Ok, now I really like this implementation. Elegant. Why the temp variables? self ifEmpty: [ ^ 0 ]. ^ self inject: self anyOne negated into: [ :sum :each | sum + each ] But more importantly, if the empty/default is 0 then what is the reason for #anyOne? Otherwise you are mixing things. self ifEmpty: [ ^ 0 ]. ^ self inject: 0 into: [ :sum :each | sum + each ]. Peter > > Thierry > > > > > > And the same for #sum: > > > > As for #detectSum: that should be removed I think. > > > > > On 01 Dec 2015, at 10:33, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > > > > > > > > > 2015-12-01 10:26 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > > > > > > On 01 Dec 2015, at 10:18, Ben Coman <btc(a)openinworld.com> wrote: > > > > > > > > On Tue, Dec 1, 2015 at 4:45 PM, Sven Van Caekenberghe <sven(a)stfx.eu> > > wrote: > > > >> I am all for a cleanup, the current situation is confusing. > > > >> The basic #sum should be fast AND work for empty collections with 0 > > as starting element. > > > > > > > >> I know why the #anyOne is used, and that use case should be > > preserved, but it is less common IMHO. > > > > > > > > I'm curious to be learn why? > > > > > > How many times have you summed a collection of things, where (1) you > > could not start from the number 0 and (2) the operation was #+ ? Me, never, > > and if I would need that, I would do an #inject:into: myself. Any counter > > examples that occur a lot ? > > > > > > wokring with things like Color > > > > > > (Color wheel:10) sum "works" > > > (Color wheel:10) newSum:#yourself " would not work" > > > > > > > > > > > > > cheers -ben > > > > > > > >> > > > >>> On 01 Dec 2015, at 09:38, Thierry Goubier <thierry.goubier(a)gmail.com> > > wrote: > > > >>> > > > >>> Hi Max, > > > >>> > > > >>> Interesting results... > > > >>> > > > >>> replacing the #yourself in newSum: cuts the runtime by a factor of > > two. > > > >>> using an [:x | x ] block cost 10% compared to a direct version of > > sum. > > > >>> > > > >>> So the fastest sum is: > > > >>> > > > >>> sum > > > >>> ^ self > > > >>> inject: > > > >>> (self ifEmpty: [ ^ 0 ] ifNotEmpty: [ self > > anyOne ]) > > > >>> into: [ :sum :each | sum + each ] > > > >>> > > > >>> And > > > >>> > > > >>> sum > > > >>> ^ self sum: [:x | x ] > > > >>> > > > >>> is 10% slower. > > > >>> > > > >>> And > > > >>> > > > >>> sum > > > >>> ^ self sum: #yourself > > > >>> > > > >>> is 100% slower (i.e. x2) > > > >>> > > > >>> It may be wise to avoid using #yourself for a block. > > > >>> > > > >>> Thierry > > > >>> > > > >>> > > > >>> 2015-12-01 9:17 GMT+01:00 Max Leske <maxleske(a)gmail.com>: > > > >>> Hi guys, > > > >>> > > > >>> Collection defines #sum:, #detectSum: and #sumNumbers:, all of which > > accomplish the same (in principal) but with subtle differences: > > > >>> > > > >>> #sum: > > > >>> - uses #inject:into: with #anyOne as the injected element and will > > thus fail for empty collections > > > >>> > > > >>> #detectSum: > > > >>> - uses ânextValue + sumâ instead of âsum + nextValueâ which makes it > > a lot slower when dealing with large numbers (primitive fails and number > > conversion is necessary) > > > >>> > > > >>> #sumNumbers: > > > >>> - same as #sum but doesnât fail for empty collections. Only good for > > numbers though. > > > >>> > > > >>> > > > >>> Benchmarks: > > > >>> > > > >>> [ 100 timesRepeat: [ (1 to: 1000000) sum: #yourself ] ] timeToRun > > 18062 > > > >>> [ 100 timesRepeat: [ (1 to: 1000000) detectSum: #yourself ] ] > > timeToRun 42391 > > > >>> [ 100 timesRepeat: [ (1 to: 1000000) sumNumbers: #yourself ] ] > > timeToRun 18096 > > > >>> > > > >>> > > > >>> > > > >>> Can we settle for a single implementation? Such as (modified from > > #sumNumbers:): > > > >>> > > > >>> newSum: aBlock > > > >>> ^ self > > > >>> inject: (self > > > >>> ifEmpty: [ 0 ] > > > >>> ifNotEmpty: [ self anyOne ]) > > > >>> into: [ :sum :each | sum + (aBlock value: each) ] > > > >>> > > > >>> This implementation combines the best of the three implementations I > > think. Benchmark: > > > >>> > > > >>> [ 100 timesRepeat: [ (1 to: 1000000) newSum: #yourself ] ] timeToRun > > 17955 > > > >>> > > > >>> > > > >>> BTW, there is also the message #sum, which suffers from the same > > problem as #sum: (the implementation is basically a copy). #sum could be > > implemented as > > > >>> > > > >>> sum > > > >>> ^ self sum: [ :x | x ] > > > >>> > > > >>> > > > >>> As for the name for the new method, I suggest #sum:. > > > >>> > > > >>> Cheers, > > > >>> Max > > > >>> > > > >> > > > >> > > > > > > > > > > > > > > > > > > > -- Peter

Dec. 1, 2015

Re: [Pharo-dev] what happened to the monkey

by Christophe Demarey

Le 30 nov. 2015 Ã 15:37, Stephan Eggermont a Ã©crit : > On 30-11-15 11:06, Nicolai Hess wrote: >> no issue validation since last weekend. > > We now get timeout within a few minutes yes Jenkins messed up build numbers .... now back to normal

Dec. 1, 2015