|
in reply to Re: OOP/Linked List Question
in thread OOP/Linked List Question
I thank all of you for your insight. Each one of you brought something useful to the table.
One reason I was interested in learning how to create a linked list data type is because of an app I am programming. I am mainly trying to improve the speed of one operation: removing or adding a record into the middle of a list. When done generically, the operation gets expensive as the number of records or nodes increase. Instead of shifting all the list elements up or down, I would prefer to just delete a node an update a pointer. I am probably making it more difficult than it has to be. Once I am able to understand the quickest way to do this I plan on creating another 'good ole ADT classic', the binary search tree.
I'll post something this weekend for you hardcore coders with nothing better to do so you can see the project I am working on. It is called FACT. It simply translates mono-alphabetic substitution ciphers using an algorithmic/AI approach hybrid. I am attempting to solve cryotoquips quicker than the app located here: http://www.blisstonia.com/software/Decrypto/ . I believe by incorporating his pattern idea along with a group of AI rules, the results could be returned quicker.
Thanks again for all of your insight,
hok_si_la |
Re^3: OOP/Linked List Question
by BrowserUk (Patriarch) on Feb 08, 2005 at 02:26 UTC
|
Instead of shifting all the list elements up or down, I would prefer to just delete a node an update a pointer.
How big is your list?
I ask for two reasons:
- If your list is large, using hashes or arrays to create your linked list will cost you lots of memory.
- Despite it's O(N) credentials, splice is remarkably adept at inserting things into the middle of even fairly long ( < ~ 20,000 elements ) lists.
And sometimes, the easy option is good enough. If your list is long enough for the cost of spliceing to become a problem, then you will also be approaching that point at which contructing linked lists from either hashes or arrays starts to consume very large volumes of memory.
Using a heap, or even a string-based list may prove to be fast enough whilst keeping your memory consumption with the range of sanity.
Examine what is said, not who speaks.
Silence betokens consent.
Love the truth but pardon error.
| [reply]
[d/l] |
|
|
BrowserUk,
The list in my future code would be dynamic in size, and would contain anywhere from 50-1500 elements. I certainly obtained a ton of good advice on the topic. I need to consult my old operation cost charts from school, and play with a few of the ideas to decide which data type would be a best fit for my app. I am really looking forward to getting this running.
Hok_si_la
| [reply] |
|
|
Well, have fun. Just remeber that O-notation comparisons of different algorithms general carry an unstated "all other things being equal" clause.
That is, an O(N) algorithm written in C (like splice), may outform a O(1+a few bits) algorithm written in Perl, if N is fairly small (and 50-1500 is small in this context) and those "few bits" consitute several lines of Perl.
Examine what is said, not who speaks.
Silence betokens consent.
Love the truth but pardon error.
| [reply] |
|
