This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

link list

Hello everyone,
I am studying link list in c
I have a project in which I have lookup table of rpm (clocks used to load the timer used for motor).
This rpm table, I am taking in an array
Now I want to implement a link list which will access the rpm from table and load it to timer of clock used for running the motor
Is it possible
Because as I am studying the link list, in that it is mentioned that link list is used instead of array
Is it possible to access an array elements using link list ?
If yes, then pls suggest me some link for it
Correct me if I am wrong
Thank u all

Parents
  • But what does "if you want to totally ignore efficiency" mean?
    exatclly what it says. If I make a one off I will want to ignore anything that will increase developement costs. If I make something that is to be produced in huge numbers (my 'record' is 680,000) I will want to ignore anything that will increase unit cost. If I make something where throughput is critical I will want to ignore anything that is not the fastest possible code in areas where it matters.
    The reason we learn all these container object types in school is just that every problem isn't identical. Because of this, the word efficient isn't really meaningful unless specifically qualified. Efficient for what? Efficient to implement in few lines of code? Efficient for finding random data? Efficient for finding spatially related data? Efficient for inserting data? Efficient for removing data? Efficient memory usage? Efficient to sort? Efficient to debug? Efficient to extend?
    none of the above, but efficient for the processor (i.e. throughput). There would be no other reason to have 'architecture' in the title.

    Erik

Reply
  • But what does "if you want to totally ignore efficiency" mean?
    exatclly what it says. If I make a one off I will want to ignore anything that will increase developement costs. If I make something that is to be produced in huge numbers (my 'record' is 680,000) I will want to ignore anything that will increase unit cost. If I make something where throughput is critical I will want to ignore anything that is not the fastest possible code in areas where it matters.
    The reason we learn all these container object types in school is just that every problem isn't identical. Because of this, the word efficient isn't really meaningful unless specifically qualified. Efficient for what? Efficient to implement in few lines of code? Efficient for finding random data? Efficient for finding spatially related data? Efficient for inserting data? Efficient for removing data? Efficient memory usage? Efficient to sort? Efficient to debug? Efficient to extend?
    none of the above, but efficient for the processor (i.e. throughput). There would be no other reason to have 'architecture' in the title.

    Erik

Children
  • "none of the above, but efficient for the processor (i.e. throughput). There would be no other reason to have 'architecture' in the title."

    But my point: "Efficient for finding random data" does mean efficient for the processor.

    But my point: "Efficient for finding spatially related data" does mean efficient for the processor.

    But my point: "Efficient for inserting data" does mean efficient for the processor.

    But my point: "Efficient for removing data" does mean efficient for the processor.

    But my point: "Efficient memory usage" does mean efficient for the processor.

    But my point: "Efficient to sort" does mean efficient for the processor.

    It is all about architecture. For some situations, lists are the #1 champ. They are 100% perfect for some operations. A ring-buffer allows perfect inserts in one end and perfect removals in the other end. But try inserting or removing in the middle.

    A dual-linked list can be spliced in constant time. Suggest any alternative that can beat a list for splicing in the middle!

    They are marvelous for sorted priority queues.

    A trie - a special form of tree/linked list - is a champ at allowing log-n search (the best you can get with the exception of a direct lookup) while at the same time supporting optimum forward and backward iteration. A hash can do constant-time searches, but try to iterate a hash table in sorted order...

    Maybe you call lists inefficient because you apply your concept of a list on some virtual (for us unknown) problem that may not be suitable for a list. But for a large class of problems, there are no other solution that can do better, i.e. be more efficient for your little processor, than a list.

    All CS programs has at least one course where abstract data types are covered, and where they are compared when it comes memory usage and how fast they are for different operations. A sequential scan of a list is O(N) - the worst - but an insert directly after a known element is O(1) - the best. But the O(N) to locate an item in a list may directly become O(log N) if the list is formed as a trie. That is the best you can manage in a sorted vector too. Except that a sorted vector takes O(N) amortized time to insert a random element. The trie does it in O(log N), totally spanking a vector.

    Small processor or supercomputer doesn't matter. O(N), O(log N) or O(1) does matter, and it takes a problem description and design work to figure out if a list will be the perfect choice or not. But never call it inefficient unless you specify a usage where it really is inefficient compared to another data structure. That is the same as saying a 8051 is inefficient! Or an ARM is inefficient. Or an Opteron is inefficient. Or English is inefficient. They all are, depending on criteria.

  • But my point: "Efficient for finding random data" does mean efficient for the processor.

    But my point: "Efficient for finding spatially related data" does mean efficient for the processor.

    But my point: "Efficient for inserting data" does mean efficient for the processor.

    But my point: "Efficient for removing data" does mean efficient for the processor.

    But my point: "Efficient memory usage" does mean efficient for the processor.

    But my point: "Efficient to sort" does mean efficient for the processor.

    all correct IF a linked list is the right choice to what the OP is doing". What you mention can, when using the '51 architecture in many cases be done much more effcient with an array of pointers. Since we do not know what the OP is dealing with, I include a part of my previous post
    By the way, this brings up a different issue, where so many posts fail to state "what for".

    so, we are discussing different approaches - which is fine - however which is the best depend on the (OPs) application.

    Erik