Talk:Doubly-linked list/Definition: Difference between revisions
→Python attitude problem
(→Python attitude problem: Not! (For which the expected reply is: is-too!)) |
|||
| (4 intermediate revisions by 3 users not shown) | |||
Line 16:
==Task definition is unclear?==
What does it mean "The structure should not allow circular loops"? To me, it's the design of data structure, which should support that; however, I seem to see in the some examples that it's the attached code which takes care about that.
: I also want to know. Is this requirement intended to rule out circular implementations of the doubly linked lists which use a "sentinel node" to eliminate corner cases? [[User:Kazinator|Kazinator]] ([[User talk:Kazinator|talk]]) 03:34, 16 October 2016 (UTC)
: Note also that a doubly-linked list is inherently circular. Between every node and its predecessor, if it has one, there is a circular relationship: the node points to its predecessor and its predecessor points to the node. That is a reference cycle. Ergo, this task description is flawed: a doubly-linked list without "circular loops" is a direct contradiction. Maybe the intent is to say the operations on the list must check for corruption? Such that if a node is to be added to a doubly-linked list, the operation must fail/assert/throw if node is already entangled in a doubly linked list? [[User:Kazinator|Kazinator]] ([[User talk:Kazinator|talk]]) 15:33, 16 October 2016 (UTC)
And the code itself, by the way, isn't required by this task, though it would clearly be useful to have data structures together with associated code for working with them. Should we update the task definition (and possibly make existing examples invalid)?[[User:Avmich|Avmich]] 01:36, 12 November 2009 (UTC)
Line 29 ⟶ 31:
:[[Tree traversal#Python]] takes a different tack and does show the use of named_tuples in creating a tree of data, but then that task is more than "show the datastructure".
:Of course, one could write a class implementing a doubly linked list in interpreted Python and append it to the Python section of the task, but I think my comment would still hold. --[[User:Paddy3118|Paddy3118]] 07:01, 10 June 2011 (UTC)
::I said, linnked list is for algorithms, not everyday data storage. The value of linked list is that connectivity info is stored on the elements, not the container. What if your job is sorting thought a set of nodes and connectivity rules, and separate nodes or edges into a set of lists to begin with? When you have only local connectivity infomation to work on, you could either use a linked list, or look up who's connected to whom in a dictionary--which is the samething really, the point is: you don't have a nicely indexed list to use yet. It's not like C people prefer linked lists over consecutively indexed arrays if it were possible, but sometimes complexity or efficiency simply won't allow it. -- [[User:Ledrug|Ledrug]] 21:33, 10 June 2011 (UTC)
::: Was this a question about problems like [[Resistor mesh]]? --[[User:Rdm|Rdm]] ([[User talk:Rdm|talk]])
::: I completely agree with Ledrug. The Python list is a container; it doesn't address problems that require the graph properties of a list. You can't even get a handle on a list node and ask, what is the successor? A solution to this task is possible in Python; the pontificating text currently in its place is a cop out.[[User:Kazinator|Kazinator]] ([[User talk:Kazinator|talk]]) 01:59, 16 June 2017 (UTC)
| |||