Re: Skybuck's Universal Code 5 (The Native Version)

Now that a new day has broken it's time to clearify some things about my

> recent invention hahahahaha =D > > 1. It does look like a linked list. However linked lists are usually used > to store individual elements. > > In this case the entire linked list is a single element or integer. It's > one big integer. > > A scalable integer for that matter. > > 2. I believe the linked list is a better structure than an array. > > An array has troubles growing. The array will collide with other structure > in memory. > > When that happens the array needs to be moved, which means an expensive > copy. > > A linked list does not have this drawback. > > Thus I believe the linked list could prove to be a faster data structure > on the long run. > > What is true and what is not true remains to be seen and might be > different per usage case. > > However the linked list has pretty much consistent performance. It will > functions longer in fragmented memory than a huge array. > > Huge arrays will start to fail in fragmented memory. And defragmentation > will need to occur for array's. Not so for linked lists. > > This linked list can function very long before it becomes a problem. > > Finally there is a performance penalty for linked list where > arbitrary/random memory positions are used. > > This is not free. Even RAM has I/O limitation. Each access for RAM > requires time. However sequantially accessed data is much faster than > randomly accessed data. > > This speaks in favor for the array. However I have also mentioned > drawbacks for arrays. > > It's hard to say if the adventage of the array outperforms the drawback of > the array. > > Finally a linked list can perform rougly the same as the array if the > memory positions are chosen to be near each other. > > Thus the linked list is a more flexible structure and can adept more > flexibly to different operating conditions. > > Now some other operating requirements. > > For large integers it's necessary to be able to move back forth through > the integer list. > > For example multiplication and division probably require to be able to go > up and down the list. > > Or maybe multiplication and division require only to be able to re-iterate > the list. > > Hmm let's see, multiplication might be done via re-iterate. > > However division works from the opposite site and starts at the largest > integers. > > This might create a little problem. > > The division algorithm must iterate to the top. But then it has no way to > return to the bottom. > > Unless it keeps track of all the integer it encountered. > > This is a clear drawback. > > However different solutions come to mind: > > Solution 1: > > 1. Alter the universal code, by making it a doubly linked list. This would > tripple memory requirements. Which is undesirable. > > 2. Keep track of pointers/elements during algorithms. Provide a recycle > list of elements/integer/pointers for fast list building. > > This makes algorithms must more complex which is also kinda unreliable.

Little correction: I meant undesirable, not necessary unreliable though it has nice ring to it as well :)

Which solution is chosen is up to the implementor. > > Remember, this is just an idea, I do not recommend you follow any ideas of > mine. If you do follow any ideas of mine, it's your own risk :) > > Bye, > Skybuck. >
Reply to
Skybuck Flying
Loading thread data ...

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.