about sorted
Locked
 
|
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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > Pharo-project mailing list [hidden email] 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 >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] 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." > 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 >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
>
> > > As soon as we have an inlining jit, the above benchmarks should give the same results. > Thanks for the explanation. I'm atheist but tell me where I should lit a candle and I will do it immediately. :) Stef _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |