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

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

by Ferlicot D. Cyril

Le 20/12/2015 12:59, Max Leske a Ã©crit : > I would like to wrap up this discussion. > > > While I think that iterators are an intriguing idea I also believe that > they are beyond the scope of this issue. If anybody wants to follow up > on iterators (or unit types for that matter) please start a new thread / > issue. > > > I propose to use Svenâs version for #sum:ifEmpty:. The result would be > these three methods: > > sum > ^ self > sum: [ :each | each ] > ifEmpty: [ 0 ] > > sum: aBlock > ^ self > sum: aBlock > ifEmpty: [ self errorEmptyCollection ] > > sum: aBlock ifEmpty: emptyBlock > | sum sample | > self isEmpty ifTrue: [ ^ emptyBlock value ]. > sample := self anyOne. > sum := self > inject: sample > into: [ :accum :each | accum + (aBlock value: each) ]. > ^ sum - sample > > > Iâve attached a couple of benchmark results below. To me they show that > 1. the new implementation is maybe a tiny bit slower but insignificantly > so (if youâre going for performance youâll probably write your own > optimised version anyway) > 2. there is no need to duplicate the code (like #sum and #sum: currently > do). Itâs perfectly fine to delegate to #sum:ifEmpty: > > > > In addition to the above changes I would like to remove #detectSum: (-> > #sum:) and #sumNumbers (-> #sum). > > > Note that once we agree on changing this API, we will need to also > change #detectMin:, #detectMax:, #min, #max as well as all overrides > (e.g. RunArray, Interval) of these and of #sum et. al. to stay > consistent. The changes would of course be in line with this change, > such that every operation has a unary selector with a sensible default, > one that takes a block and throws an error for empty collections and a > third that takes a block for the iteration and one for the empty case. > > > Please cast your vote for these changes: > > 1. Do you agree to changing #sum and #sum: in the suggested way? > Yes > 2. Do you agree to the removal of #detectSum:? > Yes > 3. Do you agree to the removal of #sumNumbers? > Yes > 4. Do you agree that the #max and #min selectors also need to be adapted? > Yes > > > Thanks for you help. > > Cheers, > Max > > > > > > Benchmarks > ============ > (Note that these arenât very good benchmarks. Thereâs quite some > variation on each run.) > > > Machine: > MacBook Pro (15-inch, Early 2011) > CPU: 2.2 GHz Intel Core i7 > Memory: 8 GB 1333 MHz DDR3 > Disk: APPLE SSD TS512C (500 GB) > > > Benchmarks of the current versions: > > [ (1 to: 1000000) asArray sum ] benchFor: 10 seconds. > 75 iterations, 7.470 per second > > [ (1 to: 1000000) asArray sum: [ :e | e ] ] benchFor: 10 seconds. > 72 iterations, 7.128 per second > > > [ (1 to: 100) asArray sum ] benchFor: 10 seconds. > 1,189,477 iterations, 118,912 per second > > > [ (1 to: 100) asArray sum: [ :e | e ] ] benchFor: 10 seconds. > 1,171,467 iterations, 117,112 per second > > > > Benchmarks of the new versions: > > [ (1 to: 1000000) asArray sum ] benchFor: 10 seconds. > 73 iterations, 7.244 per second > > [ (1 to: 1000000) asArray sum: [ :e | e ] ] benchFor: 10 seconds. > 75 iterations, 7.480 per second > > [ (1 to: 1000000) asArray sum: [ :e | e ] ifEmpty: [ 0 ] ] benchFor: 10 > seconds. > 72 iterations, 7.141 per second > > > [ (1 to: 100) asArray sum ] benchFor: 10 seconds. > 1,115,827 iterations, 111,560 per second > > [ (1 to: 100) asArray sum: [ :e | e ] ] benchFor: 10 seconds. > 1,154,595 iterations, 115,425 per second > > [ (1 to: 100) asArray sum: [ :e | e ] ifEmpty: [ 0 ] ] benchFor: 10 seconds. > 1,102,358 iterations, 110,203 per second > -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France

Dec. 22, 2015

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

by Nicolai Hess

2015-12-20 12:59 GMT+01:00 Max Leske <maxleske(a)gmail.com>: > > > I propose to use Svenâs version for #sum:ifEmpty:. The result would be > these three methods: > > sum > ^ self > sum: [ :each | each ] > ifEmpty: [ 0 ] > > sum: aBlock > ^ self > sum: aBlock > ifEmpty: [ self errorEmptyCollection ] > > sum: aBlock ifEmpty: emptyBlock > | sum sample | > self isEmpty ifTrue: [ ^ emptyBlock value ]. > sample := self anyOne. > sum := self > inject: sample > into: [ :accum :each | accum + (aBlock value: each) ]. > ^ sum - sample > > > Iâve attached a couple of benchmark results below. To me they show that > 1. the new implementation is maybe a tiny bit slower but insignificantly > so (if youâre going for performance youâll probably write your own > optimised version anyway) > 2. there is no need to duplicate the code (like #sum and #sum: currently > do). Itâs perfectly fine to delegate to #sum:ifEmpty: > > > > In addition to the above changes I would like to remove #detectSum: (-> > #sum:) and #sumNumbers (-> #sum). > there is no #sumNumbers, only #sumNumbers: > > > Note that once we agree on changing this API, we will need to also change > #detectMin:, #detectMax:, #min, #max as well as all overrides (e.g. > RunArray, Interval) of these and of #sum et. al. to stay consistent. The > changes would of course be in line with this change, such that every > operation has a unary selector with a sensible default, one that takes a > block and throws an error for empty collections and a third that takes a > block for the iteration and one for the empty case. > > > Please cast your vote for these changes: > > 1. Do you agree to changing #sum and #sum: in the suggested way? > yes > > 2. Do you agree to the removal of #detectSum:? > yes > > 3. Do you agree to the removal of #sumNumbers? > yes > > 4. Do you agree that the #max and #min selectors also need to be adapted? > hm. I like the "detect". If aCollection detectMax: aBlock becomes aCollection max: aBlock it looks too similar to aCollection size max: aValue But I could live with that :) > > > Thanks for you help. > > Cheers, > Max > > > > > > Benchmarks > ============ > (Note that these arenât very good benchmarks. Thereâs quite some variation > on each run.) > > > Machine: > MacBook Pro (15-inch, Early 2011) > CPU: 2.2 GHz Intel Core i7 > Memory: 8 GB 1333 MHz DDR3 > Disk: APPLE SSD TS512C (500 GB) > > > Benchmarks of the current versions: > > [ (1 to: 1000000) asArray sum ] benchFor: 10 seconds. > 75 iterations, 7.470 per second > > [ (1 to: 1000000) asArray sum: [ :e | e ] ] benchFor: 10 seconds. > 72 iterations, 7.128 per second > > > [ (1 to: 100) asArray sum ] benchFor: 10 seconds. > 1,189,477 iterations, 118,912 per second > > > [ (1 to: 100) asArray sum: [ :e | e ] ] benchFor: 10 seconds. > 1,171,467 iterations, 117,112 per second > > > > Benchmarks of the new versions: > > [ (1 to: 1000000) asArray sum ] benchFor: 10 seconds. > 73 iterations, 7.244 per second > > [ (1 to: 1000000) asArray sum: [ :e | e ] ] benchFor: 10 seconds. > 75 iterations, 7.480 per second > > [ (1 to: 1000000) asArray sum: [ :e | e ] ifEmpty: [ 0 ] ] benchFor: 10 > seconds. > 72 iterations, 7.141 per second > > > [ (1 to: 100) asArray sum ] benchFor: 10 seconds. > 1,115,827 iterations, 111,560 per second > > [ (1 to: 100) asArray sum: [ :e | e ] ] benchFor: 10 seconds. > 1,154,595 iterations, 115,425 per second > > [ (1 to: 100) asArray sum: [ :e | e ] ifEmpty: [ 0 ] ] benchFor: 10 > seconds. > 1,102,358 iterations, 110,203 per second > >

Dec. 22, 2015

Re: [Pharo-dev] VM error in Arch Linux

by Ferlicot D. Cyril

Le 22/12/2015 11:14, nacho a Ã©crit : > Hi Folks, > I've installed pharo-vm and pharo-launcher from AUR as stated in the pharo > site. > Everything works fine for Pharo 4. > But when I try to load a Pharo 5 image I get the following error: > This interpreter (vers. 6502) cannot read file image (vers. 6521) > > and when I do pharo --version: > 3.9-7 #1 Thu Dec 17 00:38:38 CET 2015 gcc 4.6.3 [Production ITHB VM] > NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: > 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Dec 17 2015 > NBCogit NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: > 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Dec 17 2015 > https://github.com/pharo-project/pharo-vm.git Commit: > bad6fa2684afcf1d7cdb485f11049a4a4290fbc8 Date: 2015-12-14 12:47:06 +0100 By: > Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #15024 > Linux pharo-linux 3.2.0-31-generic-pae #50-Ubuntu SMP Fri Sep 7 16:39:45 UTC > 2012 i686 i686 i386 GNU/Linux > plugin path: /usr/share/pharo-vm/ [default: /usr/share/pharo-vm/] > > > Any clues? > Hi, Since last week a new VM is use for Pharo 5 beta. You need to download the new VM on http://files.pharo.org/vm/pharo-spur32/. Then you need to update Pharo Launcher. For now the easiest way I think is to enable the development mode in PharoLauncher, go in Monticello, and load the last version of Pharo Launcher core. Later I think that a new release of Pharo Launcher will make thing easier. Then you can disable the development mode and do Alt + Shift + S to save you image. After this everything should be fine. > Thanks in advance > Nacho > > > > ----- > Nacho > Smalltalker apprentice. > Buenos Aires, Argentina. > -- > View this message in context: http://forum.world.st/VM-error-in-Arch-Linux-tp4868239.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France

Dec. 22, 2015

Re: [Pharo-dev] VM error in Arch Linux

by phil＠highoctane.be

I guess that that image is a Spur one, requiring a Spur VM. Phil On Tue, Dec 22, 2015 at 11:14 AM, nacho <0800nacho(a)gmail.com> wrote: > Hi Folks, > I've installed pharo-vm and pharo-launcher from AUR as stated in the pharo > site. > Everything works fine for Pharo 4. > But when I try to load a Pharo 5 image I get the following error: > This interpreter (vers. 6502) cannot read file image (vers. 6521) > > and when I do pharo --version: > 3.9-7 #1 Thu Dec 17 00:38:38 CET 2015 gcc 4.6.3 [Production ITHB VM] > NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: > 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Dec 17 2015 > NBCogit NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: > 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Dec 17 2015 > https://github.com/pharo-project/pharo-vm.git Commit: > bad6fa2684afcf1d7cdb485f11049a4a4290fbc8 Date: 2015-12-14 12:47:06 +0100 > By: > Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #15024 > Linux pharo-linux 3.2.0-31-generic-pae #50-Ubuntu SMP Fri Sep 7 16:39:45 > UTC > 2012 i686 i686 i386 GNU/Linux > plugin path: /usr/share/pharo-vm/ [default: /usr/share/pharo-vm/] > > > Any clues? > > Thanks in advance > Nacho > > > > ----- > Nacho > Smalltalker apprentice. > Buenos Aires, Argentina. > -- > View this message in context: > http://forum.world.st/VM-error-in-Arch-Linux-tp4868239.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

Dec. 22, 2015

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

by Denis Kudriashov

Hi My vote: > 1. Do you agree to changing #sum and #sum: in the suggested way? > yes but I prefer #sum: return zero too for empty collections > 2. Do you agree to the removal of #detectSum:? > yes > > 3. Do you agree to the removal of #sumNumbers? > yes > > 4. Do you agree that the #max and #min selectors also need to be adapted? > yes

Dec. 22, 2015

VM error in Arch Linux

by nacho

Hi Folks, I've installed pharo-vm and pharo-launcher from AUR as stated in the pharo site. Everything works fine for Pharo 4. But when I try to load a Pharo 5 image I get the following error: This interpreter (vers. 6502) cannot read file image (vers. 6521) and when I do pharo --version: 3.9-7 #1 Thu Dec 17 00:38:38 CET 2015 gcc 4.6.3 [Production ITHB VM] NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Dec 17 2015 NBCogit NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Dec 17 2015 https://github.com/pharo-project/pharo-vm.git Commit: bad6fa2684afcf1d7cdb485f11049a4a4290fbc8 Date: 2015-12-14 12:47:06 +0100 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #15024 Linux pharo-linux 3.2.0-31-generic-pae #50-Ubuntu SMP Fri Sep 7 16:39:45 UTC 2012 i686 i686 i386 GNU/Linux plugin path: /usr/share/pharo-vm/ [default: /usr/share/pharo-vm/] Any clues? Thanks in advance Nacho ----- Nacho Smalltalker apprentice. Buenos Aires, Argentina. -- View this message in context: http://forum.world.st/VM-error-in-Arch-Linux-tp4868239.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Dec. 22, 2015

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

by Nicolas Cellier

2015-12-22 10:37 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > > On 22 Dec 2015, at 10:22, Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > > > > > > 2015-12-22 3:46 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > > On Wed, Dec 2, 2015 at 3:38 AM, Tudor Girba <tudor(a)tudorgirba.com> > wrote: > > > 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. > > > > This seems the crux of the disparate viewpoints, which is why I > > suggested return a *generic* Zero object as follows... > > > > > On 04 Dec 2015, at 01:49, Ben Coman <btc(a)openInWorld.com> wrote: > > > 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 > > > > > > Nice, but generic zero can't work: you sometimes need to decide if it is > the zero of vector space, or of associated field. > > The generic zero can't behave as both say a matrix and a scalar... > > Indeed, that is what I said the first time Ben proposed this. > > But I am curious, Nicolas, what you think of this, with your math > background/interest ? > > This is what I had in old app (in the 90s): SequenceableCollection>>sum: aBlock "answer the sum of all elements after applying a Block" | sum | self isEmpty ifTrue: [^0]. sum := aBlock value: (self at: 1). 2 to: self size do: [:i | sum := sum + (aBlock value: (self at: i))]. ^sum Collection>>sum: aBlock "answer the sum of all elements after applying a Block" | sum | sum := 0. self do: [:e | sum := sum + (aBlock value: e)]. ^sum I find sum: much more expressive than inject:into: If we really find that it adds semantic value to inject:into: we may also implement optionnal: Collection>>sum: aBlock to: initialValue "answer the sum of all elements after applying a Block" | sum | sum := initialValue. self do: [:e | sum := sum + (aBlock value: e)]. ^sum Collection>>sum: aBlock ^self sum: aBlock to: 0 This way, no (#anyOne,#-) trick required, that's why I prefer sum:to: to sum:ifEmpty:... For example, I had symbolic algebra, and the #- trick would have required further simplification of the sum. So I don't have any mathematical solution, just pragmatic ones: - I agree on this: no need for many selectors, one or maximum two should be enough - I wouldn't care too much and would just answer 0 for empty collection because we have inject:into: or optionnally sum:to: for exotic cases

Dec. 22, 2015

Re: [Pharo-dev] Any thread-safe collection for Pharo?

by Denis Kudriashov

2015-12-22 10:28 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > There is SharedQueue that I know of. > > LRUCache and TTLCache can #beThreadSafe. > > In general it is easy enough to put something in front of your collection > access. > I want something more simple which not force me to remember what is semaphore, monitor, mutex or whatever. Something like this: threadSafeCollection := AnyCollectionClass threadSafe. or threadSafeCollection := AnyCollectionInstance threadSafe. or more general threadSafeObject := AnyObjectInstance threadSafe Thread safe wrappers should allow concurrent reads which blocked on writes and writes which blocked on anything. For example collection #add: method should wait until current #do: or #add: completes. And #do: should wait until current #add: completes.

Dec. 22, 2015

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

by Sven Van Caekenberghe

> On 22 Dec 2015, at 10:22, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > > 2015-12-22 3:46 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > On Wed, Dec 2, 2015 at 3:38 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > 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. > > This seems the crux of the disparate viewpoints, which is why I > suggested return a *generic* Zero object as follows... > > > On 04 Dec 2015, at 01:49, Ben Coman <btc(a)openInWorld.com> wrote: > > 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 > > > Nice, but generic zero can't work: you sometimes need to decide if it is the zero of vector space, or of associated field. > The generic zero can't behave as both say a matrix and a scalar... Indeed, that is what I said the first time Ben proposed this. But I am curious, Nicolas, what you think of this, with your math background/interest ? > On Sat, Dec 5, 2015 at 3:12 AM, Max Leske <maxleske(a)gmail.com> wrote: > > While I think you might be on to something, I think we should take small > > steps. Iâd be happy already if we can just get rid of one superfluous method > > and provide a better API without starting to think about the deeper > > semantics. > > Sure, small steps are better, except when this hits a sticking point > that the bigger step may overcome. I think returning a generic zero > allowing the program to proceed is better than throwing an generic > error that the programmer needs to explicitly deal with. The concept > of zero is well defined for the common arithmetic functions. Just for > a thought experiment, what arithmetic functions would need to be dealt > with. > > > ArithmeticZero class >> + anObject > > ^anObject > > AritmeticZero class >> * anObject > ^ anObject zero > > AritmeticZero class >> - anObject > ^ anObject zero - anObject > > > > Also, I think thereâs a reason why Aconcagua is an external package: > > developers usually are happy to work with numbers (which are already objects > > in Smalltalk anyway) and theyâre fast. > > Sure its an external package, but when you have a collection of weight > readings for example, you want to use the internal convenient #sum > method... > { 4 kg . 5 kg . 6 kg } sum --> 16kg > { } sum + 1 kg --> 1kg > { } sum * 1 kg --> 0 kg^2 "hmmm, zero with units and > multiplication starts getting more complicated - maybe should be left > out of this discussion" > > > While #sumNumbers may *technically* be the best name (which > > we canât seem to agree onâ¦), #sum, #sum: and #sum:ifEmpty: > > form a triple that naturally fits into the naming protocol applied > > elsewhere. > > So maybe alternative naming of the generic zero... > #sum (empty --> EmptyAggregateZero) > #sum: (empty --> EmptyAggregateZero) > #sum: ifEmpty: (empty --> whatever) > > > > On Mon, Dec 21, 2015 at 12:43 AM, Sven Van Caekenberghe <sven(a)stfx.eu> > > wrote: > > Doru, > > > > For me this whole discussion started because you (the standpoint that you > > take) hijacked the best selector (#sum) for a use case that is much less > > common than adding a collection of numbers which should give 0 when empty > > (you hijack it by not wanting to return 0, which I totally understand, but > > doing so you redefine the meaning/semantics). > > > > Max's point is to make everything more consistent and remove some API. I > > support that too. > > > > Now, I like Max's proposal. > > > > But, you know, my conclusion when the thread ended was that it might be > > better to throw all these selectors away, since #inject:into: covers most > > use cases at least as well and at least as clear. > > #sum is very convenient and that lowers the barrier of entry for > newcomers over the relatively exotic #inject:into: We should keep > trying to work through the sticky points, but maybe you guys getting > together IRL is better than continuing on the mail list. > > cheers -ben

Dec. 22, 2015

Re: [Pharo-dev] Any thread-safe collection for Pharo?

by Sven Van Caekenberghe

There is SharedQueue that I know of. LRUCache and TTLCache can #beThreadSafe. In general it is easy enough to put something in front of your collection access. If you want concurrent and interleaved access to the same collection by multiple threads while modifying the collection, that is something else ;-) > On 22 Dec 2015, at 09:41, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > Hello. > > Anybody know thread-safe collections project?

Dec. 22, 2015