[Pharo-project] about sorted
Hi levente may be I did a mistake when I integrated some of your changes. I did not look at Squeak before posting (because I'm dead). Now in latest 1.1 several tests for sorted failed because nil is valued while it should not. I read the code and I do not really like the aBlockOrNil. I would prefer to have block all the time. I was wondering if your original idea was to use nil and if this is the case why you thought it was better than just passing a block. sorted "Return a new sequenceable collection which contains the same elements as self but its elements are sorted in ascending order using the #'<=' operator." ^self sorted: [:a :b| a <= b ] Stef
On Mon, 12 Apr 2010, Stéphane Ducasse wrote:
Hi levente
may be I did a mistake when I integrated some of your changes. I did not look at Squeak before posting (because I'm dead). Now in latest 1.1 several tests for sorted failed because nil is valued while it should not.
I read the code and I do not really like the aBlockOrNil.
aBlockOrNil is a bit misleading, because it can be anything that understands #value:value: or it can be nil. This means that the following binary selectors can be used (if you integrated my changes) instead of blocks: #<= #>= #< #> (or whatever you define :)). Using nil is not my idea, I took it from SortedCollection.
I would prefer to have block all the time. I was wondering if your original idea was to use nil and if this is the case why you thought it was better than just passing a block.
nil is only used for better performance. Since most of the time you only want to sort by <=. Here is a simple benchmark which do the same thing, but uses 3 different "sortBlocks": | array | array := (1 to: 100000) asArray shuffle. [ array sorted: nil ] bench "===> 4.782781984854524 per second.". [ array sorted: [ :a :b | a <= b ] ] bench "===> 1.496445940890385 per second.". [ array sorted: #<= ] bench "===> 2.740262282247015 per second." Levente
sorted "Return a new sequenceable collection which contains the same elements as self but its elements are sorted in ascending order using the #'<=' operator."
^self sorted: [:a :b| a <= b ]
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hi levente
may be I did a mistake when I integrated some of your changes. I did not look at Squeak before posting (because I'm dead). Now in latest 1.1 several tests for sorted failed because nil is valued while it should not.
I read the code and I do not really like the aBlockOrNil.
aBlockOrNil is a bit misleading, because it can be anything that understands #value:value: or it can be nil. This means that the following binary selectors can be used (if you integrated my changes) instead of blocks: #<= #>= #< #> (or whatever you define :)). Using nil is not my idea, I took it from SortedCollection.
Ok
I would prefer to have block all the time. I was wondering if your original idea was to use nil and if this is the case why you thought it was better than just passing a block.
nil is only used for better performance. Since most of the time you only want to sort by <=.
Here is a simple benchmark which do the same thing, but uses 3 different "sortBlocks":
| array | array := (1 to: 100000) asArray shuffle.
[ array sorted: nil ] bench "===> 4.782781984854524 per second.".
[ array sorted: [ :a :b | a <= b ] ] bench "===> 1.496445940890385 per second.".
[ array sorted: #<= ] bench "===> 2.740262282247015 per second."
I have to look why because for me this is a sad news. I hate this nil passing around I prefer cool block. Thanks for the information. Stef
Levente
sorted "Return a new sequenceable collection which contains the same elements as self but its elements are sorted in ascending order using the #'<=' operator."
^self sorted: [:a :b| a <= b ]
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Tue, 13 Apr 2010, Stéphane Ducasse wrote:
Hi levente
may be I did a mistake when I integrated some of your changes. I did not look at Squeak before posting (because I'm dead). Now in latest 1.1 several tests for sorted failed because nil is valued while it should not.
I read the code and I do not really like the aBlockOrNil.
aBlockOrNil is a bit misleading, because it can be anything that understands #value:value: or it can be nil. This means that the following binary selectors can be used (if you integrated my changes) instead of blocks: #<= #>= #< #> (or whatever you define :)). Using nil is not my idea, I took it from SortedCollection.
Ok
I would prefer to have block all the time. I was wondering if your original idea was to use nil and if this is the case why you thought it was better than just passing a block.
nil is only used for better performance. Since most of the time you only want to sort by <=.
Here is a simple benchmark which do the same thing, but uses 3 different "sortBlocks":
| array | array := (1 to: 100000) asArray shuffle.
[ array sorted: nil ] bench "===> 4.782781984854524 per second.".
[ array sorted: [ :a :b | a <= b ] ] bench "===> 1.496445940890385 per second.".
[ array sorted: #<= ] bench "===> 2.740262282247015 per second."
The above benchmark is a bit unfair, because the vm has special bytecodes for integer comparisons, so here is the same with strings: | array | array := (1 to: 100000) asArray shuffle replace: #asString [ array sorted: nil ] bench "===> 1.506875117724618 per second.". [ array sorted: [ :a :b | a <= b ] ] bench "===> 0.718261806428443 per second.". [ array sorted: #<= ] bench "===> 1.237842617152962 per second.".
I have to look why because for me this is a sad news.
The main cause is that block activation is not cheap.
I hate this nil passing around I prefer cool block.
As soon as we have an inlining jit, the above benchmarks should give the same results. Levente
Thanks for the information.
Stef
Levente
sorted "Return a new sequenceable collection which contains the same elements as self but its elements are sorted in ascending order using the #'<=' operator."
^self sorted: [:a :b| a <= b ]
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (2)
-
Levente Uzonyi -
Stéphane Ducasse