Sorting in LinkedList<>

  • Thread starter Thread starter martin-g
  • Start date Start date
M

martin-g

Hi.

Mostly I program in C++, and I'm not fluent in C# and .NET. In my last
project I began to use LinkedList<> and suddenly noticed that can't
find a way to sort it. Does it mean I must implement sorting for
LinkedList<> myself?

Thanks in advance

Martin
 
pvdg42 said:
So it would appear.
Perhaps this article would be helpful to you:

http://msdn2.microsoft.com/en-us/library/6tc79sx1.aspx

Thank you for answer. That's really wild... Looking through the article
I couldn't eventually select the collection class of my need. On the
one hand I want an item to be added to the container at constant time
at any position, so must use LinkeList<>. On the other hand I want to
sort the container, so I must use List<>. FCL has really strange
container organization... Only now I understood: I love STL very much...
 
martin-g said:
Thank you for answer. That's really wild... Looking through the article
I couldn't eventually select the collection class of my need. On the
one hand I want an item to be added to the container at constant time
at any position, so must use LinkeList<>. On the other hand I want to
sort the container, so I must use List<>. FCL has really strange
container organization... Only now I understood: I love STL very much...

So you want constant time insertions and the ability to sort the
collection. The List<> collection sounds like a good match.
Insertions are usually O(1) and you can call the Sort method to sort
the collection. Have you looked at SortedDictionary yet? Insertions
are a bit slower, but the items are always stored in order so there's
no need to perform a separate sort operation.

Brian
 
Brian Gideon said:
So you want constant time insertions and the ability to sort the
collection. The List<> collection sounds like a good match.
Insertions are usually O(1) and you can call the Sort method to sort
the collection. Have you looked at SortedDictionary yet? Insertions
are a bit slower, but the items are always stored in order so there's
no need to perform a separate sort operation.

Insertions into a List<> are certainly *not* O(1) in general. When
adding to the end of the list, the additions will be cheap if there's
enough room in the buffer. Otherwise, it requires a copy of all the
items after the new entry (or all the items if a new buffer is
required).

The MSDN docs say it's an O(n) operation too.
 
Jon said:
Insertions into a List<> are certainly *not* O(1) in general. When
adding to the end of the list, the additions will be cheap if there's
enough room in the buffer. Otherwise, it requires a copy of all the
items after the new entry (or all the items if a new buffer is
required).

The MSDN docs say it's an O(n) operation too.

Yeah, wow, I'm not sure what I was thinking when I wrote that. In
fact, my whole post doesn't make any since...beginning, middle, and
end. That's one of those you just wish you could take back. Ya think
I can talk Google into deleting that one :)
 
Jon said:
Insertions into a List<> are certainly *not* O(1) in general. When
adding to the end of the list, the additions will be cheap if there's
enough room in the buffer. Otherwise, it requires a copy of all the
items after the new entry (or all the items if a new buffer is
required).

The MSDN docs say it's an O(n) operation too.

So, List<> isn't a linked list, it's an array...? I suppose it would
have to be, if it's meant to be the "first choice" collection for
general use.

Does Framework 2.0 even provide a true link list? Dumb question, I
know, but we're still on 1.1.... :-)
 
Bruce said:
So, List<> isn't a linked list, it's an array...? I suppose it would
have to be, if it's meant to be the "first choice" collection for
general use.

Yes said:
Does Framework 2.0 even provide a true link list? Dumb question, I
know, but we're still on 1.1.... :-)

I was on 1.1 too, and decided to turn to 2.0 only for its LinkedList<>
generic collection. And some time later realized it's not the linked
list of my dreams.
 
Bruce said:
So, List<> isn't a linked list, it's an array...? I suppose it would
have to be, if it's meant to be the "first choice" collection for
general use.
Yes.

Does Framework 2.0 even provide a true link list? Dumb question, I
know, but we're still on 1.1.... :-)

Well, System.Collections.LinkedList still exists, and there's a generic
LinkedList as well.

Note that linked lists don't lend themselves particularly well to
efficient sorting, as sorting ideally requires efficient access to
arbitrary elements of the list.

Jon
 
Jon said:
Well, System.Collections.LinkedList still exists, and there's a generic
LinkedList as well.

I do apologise - of course there isn't a System.Collections.LinkedList,
I don't know what I was thinking of...

Jon
 
Isn't sorting basically looping and then swapping individual elements,
not really arbitrary access to somewhere in the list? A double-linked
list is just fine for sorting 'cause it's easy enough to change the
references in the nodes and swap items. Not as easy as swapping items
in an array, but not a huge problem either.

Sam

------------------------------------------------------------
We're hiring! B-Line Medical is seeking Mid/Sr. .NET
Developers for exciting positions in medical product
development in MD/DC. Work with a variety of technologies
in a relaxed team environment. See ads on Dice.com.
 
Samuel said:
Isn't sorting basically looping and then swapping individual elements,
not really arbitrary access to somewhere in the list? A double-linked
list is just fine for sorting 'cause it's easy enough to change the
references in the nodes and swap items. Not as easy as swapping items
in an array, but not a huge problem either.

Well, consider quick sort - it starts off each iteration by picking a
pivot, often by taking the half-way point within the list/sublist. That
requires an O(n) operation in a linked list. I haven't examined the
other types of sort in detail, but I suspect they would have similar
problems.

Something like a bubble sort is very easy to achieve in a linked list,
but I suspect that most of the other sorts are at least tricky to
achieve efficiently. Put it this way, you certainly wouldn't want to
use the same code to sort both types of list, even if they used the
same algorithm.

Having said all this, I did a quick search for sorting linked lists,
and a very reliable source (a friend from university :) has written up
applying mergesort to linked lists - apparently it works well:
http://www.chiark.greenend.org.uk/~sgtatham/algorithms/listsort.html

Interestingly, wikipedia has this to say (in its Mergesort page):

<quote>
Merge sort is often the best choice for sorting a linked list: in this
situation it is relatively easy to implement a merge sort in such a way
that it requires only T(1) extra space, and the slow random-access
performance of a linked list makes some other algorithms (such as
quicksort) perform poorly, and others (such as heapsort) completely
impossible.
</quote>

So it looks like my original assessment was half-right: you basically
need to treat sorting linked lists differently, and shouldn't expect
the "normal" algorithms to do well, but it's doable. It's worth noting
that the Java "I sort any list" method
java.util.Collections.sort(List<T>) achieves n log(n) performance by
dumping the list into an array, performing a merge sort on it, then
resetting the contents of the original list.

Jon
 
Samuel said:
Isn't sorting basically looping and then swapping individual elements,
not really arbitrary access to somewhere in the list? A double-linked
list is just fine for sorting 'cause it's easy enough to change the
references in the nodes and swap items. Not as easy as swapping items
in an array, but not a huge problem either.

Sam

Sam,

If the topic interests you then it's worth taking a look at skip lists.
A skip list is a linked list that maintains a sorted order. By using
them you can take a randomly order linked list and convert it into
sorted skip list in amortized O(n*log(n)) time which is on par with the
quicksort. It requires more memory than a single linked list, but less
than a double-linked list. What I find particulary fascinating is that
most implementations are non-deterministic because they use a random
number generator. There are several properties that make them great
candidates for priority queues as well.

Brian
 
Jon said:
Well, consider quick sort - it starts off each iteration by picking a
pivot, often by taking the half-way point within the list/sublist. That
requires an O(n) operation in a linked list. I haven't examined the
other types of sort in detail, but I suspect they would have similar
problems.

I've written quick sort for a linked list. The only costly operation is
finding the pivot element. After that it's pure sequential access (next
/ previous) to do the swaps. As I said, it's not that bad, but then it
will never be as fast as for an arbitrarily addressable object like an
array.
 
This from the same person that originally said insertions to List were
O(1). I think you've redeemed yourself. :-)

Unless there is a huge performance difference and sorting is something
that's done quite often, I personally would prefer not to write a
custom collection when writing a custom sorter for an existing
collection would suffice.

Sam
 
Samuel said:
Isn't sorting basically looping and then swapping individual elements,
not really arbitrary access to somewhere in the list? A double-linked
list is just fine for sorting 'cause it's easy enough to change the
references in the nodes and swap items. Not as easy as swapping items
in an array, but not a huge problem either.

Samuel,

If the topic interests you then it's worth taking a look at skip lists.
A skip list is a linked list that maintains a sorted order. By using
them you can take a randomly order linked list and convert it into
sorted skip list in amortized O(n*log(n)) time which is on par with the
quicksort. It requires more memory than a single linked list, but less
than a double-linked list. What I find particulary fascinating is that
most implementations are non-deterministic because they use a random
number generator. There are several properties that make them great
candidates for priority queues as well.

Brian
 
Samuel said:
This from the same person that originally said insertions to List were
O(1). I think you've redeemed yourself. :-)

Yeah, that was pretty embarrassing. Afterall, even Susie grade
schooler knows that a List usually has O(n) insertions :)
Unless there is a huge performance difference and sorting is something
that's done quite often, I personally would prefer not to write a
custom collection when writing a custom sorter for an existing
collection would suffice.

I don't think anyone would argue with that.
------------------------------------------------------------
We're hiring! B-Line Medical is seeking Mid/Sr. .NET
Developers for exciting positions in medical product
development in MD/DC. Work with a variety of technologies
in a relaxed team environment. See ads on Dice.com.

Based on recent performance I shouldn't send you my resume huh? :)
 
PowerCollections has a Linked List implementation with Sort
functionality? I didn't see it in the docs...

Sam

------------------------------------------------------------
We're hiring! B-Line Medical is seeking Mid/Sr. .NET
Developers for exciting positions in medical product
development in MD/DC. Work with a variety of technologies
in a relaxed team environment. See ads on Dice.com.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Back
Top