Fwd: sort: and sortBlock:

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
70 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Fwd: sort: and sortBlock:

Stéphane Ducasse
Apparently sort: is not understood by SortedCollection :(
And sortBlock: is not understood by ArrayedCollection subclasses :(
So this is cool OrderedCollection does not understand sort:

Could we dare to fix that? Does anybody have a solution?

Stef

ArrayedCollection>>sort: aSortBlock
        "Sort this array using aSortBlock. The block should take two arguments
        and return true if the first element should preceed the second one."

        self
                mergeSortFrom: 1
                to: self size
                by: aSortBlock


SortedCollection>>sortBlock: aBlock
        "Answer an instance of me such that its elements are sorted according to
        the criterion specified in aBlock."

        ^(super new: 10) sortBlock: aBlock





_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: sort: and sortBlock:

Nicolas Cellier
2009/12/23 Stéphane Ducasse <[hidden email]>:

> Apparently sort: is not understood by SortedCollection :(
> And sortBlock: is not understood by ArrayedCollection subclasses :(
> So this is cool OrderedCollection does not understand sort:
>
> Could we dare to fix that? Does anybody have a solution?
>
> Stef
>
> ArrayedCollection>>sort: aSortBlock
>        "Sort this array using aSortBlock. The block should take two arguments
>        and return true if the first element should preceed the second one."
>
>        self
>                mergeSortFrom: 1
>                to: self size
>                by: aSortBlock
>
>
> SortedCollection>>sortBlock: aBlock
>        "Answer an instance of me such that its elements are sorted according to
>        the criterion specified in aBlock."
>
>        ^(super new: 10) sortBlock: aBlock
>
>

Oh that one bugs me...
You also have

asSortedArray
asSortedCollection
asSortedCollection:
sortBy:

A bit too many selectors?

The different semantics currently are:
- sort in place  - #sort and #sort:
- make a sorted copy - #asSortedArray does except if already
isMemberOf: Array and isSorted, #sortBy: does too but is only
understood by SequenceableCollection (stupid)
- make a sorted collection that can further sort added elements -
#asSortedCollection #asSortedCollection:
#sortBlock: has 2 semantics: instance creation and modifying the sort
block of an instance...

And I would like another message to avoid all these keys asArray sort
I spreaded in trunk:
- sort in place if possible (if Sequenceable), or create a sorted
sequence otherwise
But you can understand I did not dare adding a new selector :)

Nicolas

>
>
>
> _______________________________________________
> 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
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: sort: and sortBlock:

Stéphane Ducasse
Nicolas

could we build a path to make sure that we can move on?
I would love to write new collection using traits (but I have no time :(
I should finish sometimes what I start -- geesh).

I started to implement OrderedSet (OrderedCollection no duplicate)
but I think that I want probably UniqueOrdered.
I will publish what I have done and ask for feedback and that other can improve.
I like the idea of using the TraitsTest to have coherent sets of behavior.

>> asSortedArray
> asSortedCollection
> asSortedCollection:
> sortBy:
>
> A bit too many selectors?
>
> The different semantics currently are:
> - sort in place  - #sort and #sort:
> - make a sorted copy - #asSortedArray does except if already
> isMemberOf: Array and isSorted, #sortBy: does too but is only
> understood by SequenceableCollection (stupid)
> - make a sorted collection that can further sort added elements -
> #asSortedCollection #asSortedCollection:
> #sortBlock: has 2 semantics: instance creation and modifying the sort
> block of an instance...
>
> And I would like another message to avoid all these keys asArray sort
> I spreaded in trunk:
> - sort in place if possible (if Sequenceable), or create a sorted
> sequence otherwise
> But you can understand I did not dare adding a new selector :)
>
> Nicolas








_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: sort: and sortBlock:

Adrian Kuhn
Stéphane Ducasse <stephane.ducasse@...> writes:

>  I started to implement OrderedSet (OrderedCollection no duplicate)
> but I think that I want probably UniqueOrdered.
> I will publish what I have done and ask for feedback and that other can
> improve. I like the idea of using the TraitsTest to have coherent sets of
> behavior.

Oh yeah, TreeSet ftw, missed that already sometime!

> > >> asSortedArray
> > asSortedCollection
> > asSortedCollection:
> > sortBy:

What bugs me is that #sortBy: does not what it says. I would expect that

    aCollection sortBy: [ :each | each name ]

does the same as

    aCollection sort: [ :a :b | a name <= b name ]

if you want that, I can provide a fast implementation of #sortBy:

--AA


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: sort: and sortBlock:

Mariano Martinez Peck


On Wed, Dec 23, 2009 at 4:58 PM, Adrian Kuhn <[hidden email]> wrote:
Stéphane Ducasse <stephane.ducasse@...> writes:

>  I started to implement OrderedSet (OrderedCollection no duplicate)
> but I think that I want probably UniqueOrdered.
> I will publish what I have done and ask for feedback and that other can
> improve. I like the idea of using the TraitsTest to have coherent sets of
> behavior.

Oh yeah, TreeSet ftw, missed that already sometime!

> > >> asSortedArray
> > asSortedCollection
> > asSortedCollection:
> > sortBy:

What bugs me is that #sortBy: does not what it says. I would expect that

   aCollection sortBy: [ :each | each name ]

does the same as

   aCollection sort: [ :a :b | a name <= b name ]

if you want that, I can provide a fast implementation of #sortBy:



In  those cases will be cool to write first all the tests than make the things to fail and then write the code to fix them :)
But ok...not everybody have that time.
 
--AA


_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: sort: and sortBlock:

Randal L. Schwartz
In reply to this post by Adrian Kuhn
>>>>> "Adrian" == Adrian Kuhn <[hidden email]> writes:

Adrian> What bugs me is that #sortBy: does not what it says. I would expect that

Adrian>     aCollection sortBy: [ :each | each name ]

Adrian> does the same as

Adrian>     aCollection sort: [ :a :b | a name <= b name ]

And if you could make "aCollection sortBy: #name" also do the same,
bonus points!

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: sort: and sortBlock:

Stéphane Ducasse
In reply to this post by Adrian Kuhn
>> I started to implement OrderedSet (OrderedCollection no duplicate)
>> but I think that I want probably UniqueOrdered.
>> I will publish what I have done and ask for feedback and that other can
>> improve. I like the idea of using the TraitsTest to have coherent sets of
>> behavior.
>
> Oh yeah, TreeSet ftw, missed that already sometime!

what is TreeSet?

>>>>> asSortedArray
>>> asSortedCollection
>>> asSortedCollection:
>>> sortBy:
>
> What bugs me is that #sortBy: does not what it says. I would expect that
>
>    aCollection sortBy: [ :each | each name ]
>
> does the same as
>
>    aCollection sort: [ :a :b | a name <= b name ]

Is it not that sortBy: should be used like that
        aCollection sortBy: [ :a :b | a name <= b name ] ?

> if you want that, I can provide a fast implementation of #sortBy:

Now what would be good is to have sort: for all the collections so that we can use them
polymorphically.

I do not really see the use of sortBy: except as a replacement/unification between
sortBlock: and sort:.

I really think that we should polish the collections. They are the foundation.
We should probably have a look at the moose collection extensions you did and
we ported to squeak (not all of them). They are published in Moose/CollectionExtensions

Stef

>
> --AA
>
>
> _______________________________________________
> 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
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: sort: and sortBlock:

Adrian Kuhn
Stéphane Ducasse <stephane.ducasse@...> writes:

> >> I started to implement OrderedSet (OrderedCollection no duplicate)
> >> but I think that I want probably UniqueOrdered.
> >> I will publish what I have done and ask for feedback and that other can
> >> improve. I like the idea of using the TraitsTest to have coherent sets of
> >> behavior.
> >
> > Oh yeah, TreeSet ftw, missed that already sometime!
>
> what is TreeSet?

The common data structure to implement ordered sets. Which one do you use?

--AA


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: sort: and sortBlock:

Adrian Kuhn
In reply to this post by Randal L. Schwartz
Randal L. Schwartz <merlyn@...> writes:

> And if you could make "aCollection sortBy: #name" also do the same,
> bonus points!

Even better, you get that for free thanks to Symbol>>#value: :)

--AA





_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: sort: and sortBlock:

Stéphane Ducasse
In reply to this post by Adrian Kuhn
>>>> I started to implement OrderedSet (OrderedCollection no duplicate)
>>>> but I think that I want probably UniqueOrdered.
>>>> I will publish what I have done and ask for feedback and that other can
>>>> improve. I like the idea of using the TraitsTest to have coherent sets of
>>>> behavior.
>>>
>>> Oh yeah, TreeSet ftw, missed that already sometime!
>>
>> what is TreeSet?
>
> The common data structure to implement ordered sets. Which one do you use?

OrderedCollection as in VW the order is based on addition order.

I think that what I'm implemented is more UniqueOrderedCollection than OrderedSet
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: sort: and sortBlock:

Julian Fitzell-2
In reply to this post by Nicolas Cellier
On Wed, Dec 23, 2009 at 1:45 AM, Nicolas Cellier
<[hidden email]> wrote:

> 2009/12/23 Stéphane Ducasse <[hidden email]>:
>> Apparently sort: is not understood by SortedCollection :(
>> And sortBlock: is not understood by ArrayedCollection subclasses :(
>> So this is cool OrderedCollection does not understand sort:
>>
>> Could we dare to fix that? Does anybody have a solution?
>>
>> Stef
>>
>> ArrayedCollection>>sort: aSortBlock
>>        "Sort this array using aSortBlock. The block should take two arguments
>>        and return true if the first element should preceed the second one."
>>
>>        self
>>                mergeSortFrom: 1
>>                to: self size
>>                by: aSortBlock
>>
>>
>> SortedCollection>>sortBlock: aBlock
>>        "Answer an instance of me such that its elements are sorted according to
>>        the criterion specified in aBlock."
>>
>>        ^(super new: 10) sortBlock: aBlock
>>
>>
>
> Oh that one bugs me...
> You also have
>
> asSortedArray
> asSortedCollection
> asSortedCollection:
> sortBy:
>
> A bit too many selectors?
>
> The different semantics currently are:
> - sort in place  - #sort and #sort:
> - make a sorted copy - #asSortedArray does except if already
> isMemberOf: Array and isSorted, #sortBy: does too but is only
> understood by SequenceableCollection (stupid)
> - make a sorted collection that can further sort added elements -
> #asSortedCollection #asSortedCollection:
> #sortBlock: has 2 semantics: instance creation and modifying the sort
> block of an instance...
>
> And I would like another message to avoid all these keys asArray sort
> I spreaded in trunk:
> - sort in place if possible (if Sequenceable), or create a sorted
> sequence otherwise
> But you can understand I did not dare adding a new selector :)

Funnily I just spent last week with John O'Keefe looking at
non-VASt-compatible protocol that Seaside uses, comparing it across
platforms, and pondering which pieces to include tests for in Grease
and which to stop using in Seaside. (by the way, he was happy to add a
whole bunch of "useful" protocol to their base image, which is great
news). I need to write a summary of everything we came up with as well
over the holidays, but in the meantime, here's what we came up with
around sorting:

#sortBlock: is defined by ANSI on SortedCollection as an accessor and
an instance creation method. That's what it sounds like and shouldn't
be implemented on non-sorted collections.


#asSortedCollection is defined by ANSI on Collection and returns an
instance of SortedCollection.


#sort and #sort: -- Squeak/Pharo have it on ArrayedCollection, VW has
it on SequenceableCollection, and VASt will now add it. This sorts the
instance in place.


#sorted, #sorted: -- VW already has this. VA is adding it.
Squeak/Pharo should add it, IMO, but we'll add it to Grease if not. It
returns a sorted copy of SequenceableCollections and a sorted Array of
all other collections.


#sortBy: is silly, as you mention and not supported on any other
platform. We're adding it to our lint rules as a "do not use" method.


We didn't notice #asSortedArray but I think that's a terrible name --
the pattern with #as* methods is that the thing after the "as" should
be a class. That behaviour could be easily achieved with "aCollection
sorted asArray" or "aCollection asArray sort" if really needed.


So that's what VASt/Seaside/Grease are doing... I encourage you to
follow our lead. :)

Julian

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: sort: and sortBlock:

Adrian Kuhn
In reply to this post by Stéphane Ducasse
Stéphane Ducasse <stephane.ducasse@...> writes:

> >> what is TreeSet?
> >
> > The common data structure to implement ordered sets. Which one do you use?
>
> OrderedCollection as in VW the order is based on addition order.
>
> I think that what I'm implemented is more UniqueOrderedCollection than
> OrderedSet

Okay, so all basic operations are O(n) and elements are not ordered by their
 natural order. Sounds kinda like a push-only stack with unique elements and
 "global" remove. Mebbe `UniqueStack` is a good name?

Would be nice to get a tree set also then. In a tree set all basic operations
 (add, remove, includes) are O(log n) and elements are ordered by their natural
 order. This could be called `SortedSet` even.

No tree set implementation in Smalltalk out there?

--AA


--
4th Workshop on Dynamic Languages and Applications
Submit papers by March 31, 2010. http://bit.ly/dyla2010


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: sort: and sortBlock:

Levente Uzonyi-2
In reply to this post by Adrian Kuhn
On Wed, 23 Dec 2009, Adrian Kuhn wrote:

> Stéphane Ducasse <stephane.ducasse@...> writes:

> >> I started to implement OrderedSet (OrderedCollection no duplicate)
> >> but I think that I want probably UniqueOrdered.
> >> I will publish what I have done and ask for feedback and that other can
> >> improve. I like the idea of using the TraitsTest to have coherent sets of
> >> behavior.
> >
> > Oh yeah, TreeSet ftw, missed that already sometime!
>
> what is TreeSet?

The common data structure to implement ordered sets. Which one do you use?


IMO ordered sets (where ordering means the same as in OrderedCollection)
should be implemented with a hashtable of linked elements.


Levente



--AA


_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: sort: and sortBlock:

Levente Uzonyi-2
In reply to this post by Adrian Kuhn
On Wed, 23 Dec 2009, Adrian Kuhn wrote:

> Stéphane Ducasse <stephane.ducasse@...> writes:

> >> what is TreeSet?
> >
> > The common data structure to implement ordered sets. Which one do you use?
>
> OrderedCollection as in VW the order is based on addition order.
>
> I think that what I'm implemented is more UniqueOrderedCollection than
> OrderedSet

Okay, so all basic operations are O(n) and elements are not ordered by their
  natural order. Sounds kinda like a push-only stack with unique elements and
  "global" remove. Mebbe `UniqueStack` is a good name?

Would be nice to get a tree set also then. In a tree set all basic operations
  (add, remove, includes) are O(log n) and elements are ordered by their natural
  order. This could be called `SortedSet` even.

No tree set implementation in Smalltalk out there?


There's BTree on squeaksource, I have LLRBTree (left-leaning
red-black tree) but that needs some polishing. Probably there are
other implementations too. (I think there's an AVL-tree implementation
somewhere, but i'm unsure.) Trees are rarely useful anyway.


Levente



--AA


--
4th Workshop on Dynamic Languages and Applications
Submit papers by March 31, 2010. http://bit.ly/dyla2010


_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: sort: and sortBlock:

Levente Uzonyi-2
In reply to this post by Randal L. Schwartz
On Wed, 23 Dec 2009, Randal L. Schwartz wrote:

>>>>>> "Adrian" == Adrian Kuhn <[hidden email]> writes:
>
> Adrian> What bugs me is that #sortBy: does not what it says. I would expect that
>
> Adrian>     aCollection sortBy: [ :each | each name ]
>
> Adrian> does the same as
>
> Adrian>     aCollection sort: [ :a :b | a name <= b name ]
>
> And if you could make "aCollection sortBy: #name" also do the same,
> bonus points!

Well, squeak trunk has this, try: #(1 2 3) sort: #>=.


Levente


>
> --
> Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
> <[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
> See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
>
> _______________________________________________
> 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
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: sort: and sortBlock:

Levente Uzonyi-2
In reply to this post by Adrian Kuhn
On Wed, 23 Dec 2009, Adrian Kuhn wrote:

> Stéphane Ducasse <stephane.ducasse@...> writes:

>  I started to implement OrderedSet (OrderedCollection no duplicate)
> but I think that I want probably UniqueOrdered.
> I will publish what I have done and ask for feedback and that other can
> improve. I like the idea of using the TraitsTest to have coherent sets of
> behavior.

Oh yeah, TreeSet ftw, missed that already sometime!

> > >> asSortedArray
> > asSortedCollection
> > asSortedCollection:
> > sortBy:

What bugs me is that #sortBy: does not what it says. I would expect that

     aCollection sortBy: [ :each | each name ]

does the same as

     aCollection sort: [ :a :b | a name <= b name ]

if you want that, I can provide a fast implementation of #sortBy:


Not all collections are sortable and #sort: is sorting in-place, so it's
hardly doable.


Levente



--AA


_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: sort: and sortBlock:

Levente Uzonyi-2
In reply to this post by Julian Fitzell-2
On Wed, 23 Dec 2009, Julian Fitzell wrote:

>
> Funnily I just spent last week with John O'Keefe looking at
> non-VASt-compatible protocol that Seaside uses, comparing it across
> platforms, and pondering which pieces to include tests for in Grease
> and which to stop using in Seaside. (by the way, he was happy to add a
> whole bunch of "useful" protocol to their base image, which is great
> news). I need to write a summary of everything we came up with as well
> over the holidays, but in the meantime, here's what we came up with
> around sorting:
>
> #sortBlock: is defined by ANSI on SortedCollection as an accessor and
> an instance creation method. That's what it sounds like and shouldn't
> be implemented on non-sorted collections.

+1

>
>
> #asSortedCollection is defined by ANSI on Collection and returns an
> instance of SortedCollection.
>

And this shouldn't be used for sorting.

>
> #sort and #sort: -- Squeak/Pharo have it on ArrayedCollection, VW has
> it on SequenceableCollection, and VASt will now add it. This sorts the
> instance in place.
>

The problem here is that not all SequenceableCollections are sortable,
for example instances of Interval can't be sorted. In squeak trunk
ArrayedCollection and OrderedCollection understand both.

>
> #sorted, #sorted: -- VW already has this. VA is adding it.
> Squeak/Pharo should add it, IMO, but we'll add it to Grease if not. It
> returns a sorted copy of SequenceableCollections and a sorted Array of
> all other collections.
>

+1, except for SequenceableCollection, see above

>
> #sortBy: is silly, as you mention and not supported on any other
> platform. We're adding it to our lint rules as a "do not use" method.
>

+1

>
> We didn't notice #asSortedArray but I think that's a terrible name --
> the pattern with #as* methods is that the thing after the "as" should
> be a class. That behaviour could be easily achieved with "aCollection
> sorted asArray" or "aCollection asArray sort" if really needed.
>

+1, also note that in squeak/pharo #as* methods have semantic differences


Levente

>
> So that's what VASt/Seaside/Grease are doing... I encourage you to
> follow our lead. :)
>
> Julian
>
> _______________________________________________
> 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
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: sort: and sortBlock:

Stéphane Ducasse
In reply to this post by Adrian Kuhn

On Dec 23, 2009, at 6:08 PM, Adrian Kuhn wrote:

> Stéphane Ducasse <stephane.ducasse@...> writes:
>
>>>> what is TreeSet?
>>>
>>> The common data structure to implement ordered sets. Which one do you use?
>>
>> OrderedCollection as in VW the order is based on addition order.
>>
>> I think that what I'm implemented is more UniqueOrderedCollection than
>> OrderedSet
>
> Okay, so all basic operations are O(n) and elements are not ordered by their
> natural order. Sounds kinda like a push-only stack with unique elements and
> "global" remove. Mebbe `UniqueStack` is a good name?

kind of I prefer UniqueOrderedCollection now in VW they have a kind of equivalent named OrderedSet
which is not a treeSet

> Would be nice to get a tree set also then. In a tree set all basic operations
> (add, remove, includes) are O(log n) and elements are ordered by their natural
> order.
Yes I see.

> This could be called `SortedSet` even.
>
> No tree set implementation in Smalltalk out there?

Not from me :)

Stef

>
> --AA
>
>
> --
> 4th Workshop on Dynamic Languages and Applications
> Submit papers by March 31, 2010. http://bit.ly/dyla2010
>
>
> _______________________________________________
> 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
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: sort: and sortBlock:

Stéphane Ducasse
In reply to this post by Levente Uzonyi-2

On Dec 23, 2009, at 6:09 PM, Levente Uzonyi wrote:

> On Wed, 23 Dec 2009, Adrian Kuhn wrote:
>
>> Stéphane Ducasse <stephane.ducasse@...> writes:
>
>> >> I started to implement OrderedSet (OrderedCollection no duplicate) >> but I think that I want probably UniqueOrdered. >> I will publish what I have done and ask for feedback and that other can
>> >> improve. I like the idea of using the TraitsTest to have coherent sets of
>> >> behavior. > > Oh yeah, TreeSet ftw, missed that already sometime!
>> what is TreeSet?
>
> The common data structure to implement ordered sets. Which one do you use?
>
>
> IMO ordered sets (where ordering means the same as in OrderedCollection) should be implemented with a hashtable of linked elements.

Why not an OrderedCollection?
if we mean UniqueOrderedCollection
For an OrderedSet I imagine that this is because you want a constant access to elements (which happend to be ordered)?
Stef
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: sort: and sortBlock:

Stéphane Ducasse
In reply to this post by Levente Uzonyi-2
>>
>
> What bugs me is that #sortBy: does not what it says. I would expect that
>
>    aCollection sortBy: [ :each | each name ]
>
> does the same as
>
>    aCollection sort: [ :a :b | a name <= b name ]
>
> if you want that, I can provide a fast implementation of #sortBy:
>
>
> Not all collections are sortable and #sort: is sorting in-place, so it's hardly doable.

But it would be nice to have sort: and sortBlock: polymorph.
Because right now we cannot have OrderedCollection and Array or SortedCollection interchanged.

Stef
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
1234