Thanks again.

Thanks again.

I see the challenge did get you thinking Of course, there are usually a bunch of other issues that come along with a problem like this, and I think you may well have covered most, if not all, of them.

I tried to write the definition of the problem in a very compact way in an attempt to focus people on the algorithm rather than the code. This of course forced me (and you guys) to make some assumptions about the code where this might occur.

In an ideal world, there would of course be some form of list management structure/object that ensures that a “loop” such as this would never occur. My assumption here is that, even if there is a list management structure, there is a bug in the code which results in the list incorrectly becoming a circular list – at an unknown point.

That’s probably the key piece of information that I left out of the problem spec, but I did that for a reason also – to see what solutions come through which attempt to cater for any loop scenario.

I have actually seen this sort of issue happen in the real world. The most common place you see things like this (in my experience) is where code is attempting to manage one or more “free lists” where the nodes can switch between the lists.

Example: You’re writing a little memory manager that is responsible for allocating a block of memory which can be used by a collection of objects, let’s say of type T. On start-up, the memory manager allocates a chunk of memory to allow for the use of up to N lots of T at any given time, and it manages that chunk of memory using two separate free lists. At the start, the “allocated” list is empty, and the “unallocated” list has all the nodes in it. As the program continues to execute, and calling objects request allocation of memory for type T, the memory allocator simply removes a node from the “unallocated” list to the “allocated” list (by switching a few pointers around), and returns a reference to the newly “allocated” instance of T for the caller to use. Depending on how good (or bad :)) the author of this memory manager was, issues such as loops in the list can unfortunately become a reality. In this scenario, it is possible, through incorrect ordering of steps or bad management of pointers across the two structures, that the loop can occur almost anywhere in either of the free lists.

So while this may be unlikely when, for the most part, there are already a bunch of implementations of lists that people use day in day out it can actually appear in the wild. The purpose of the question was to attempt to come up with a way of determining if a list contains such a loop. I see it more as a debugging utility than anything else.

You’re entitled to get pedantic That’s what this is about! I think your posts are interesting, and in the case where an official “singly linked-list” (or is it “singularly”?) becomes an official “circular linked-list”, your solution would indeed be fastest. Of course, in the case where we don’t exactly know where the loop in the list occurs, this wouldn’t give us the result we’re looking for, and this is where Keith’s solution shines.

Thanks for the posts guys

I see the challenge did get you thinking Of course, there are usually a bunch of other issues that come along with a problem like this, and I think you may well have covered most, if not all, of them.

I tried to write the definition of the problem in a very compact way in an attempt to focus people on the algorithm rather than the code. This of course forced me (and you guys) to make some assumptions about the code where this might occur.

In an ideal world, there would of course be some form of list management structure/object that ensures that a “loop” such as this would never occur. My assumption here is that, even if there is a list management structure, there is a bug in the code which results in the list incorrectly becoming a circular list – at an unknown point.

That’s probably the key piece of information that I left out of the problem spec, but I did that for a reason also – to see what solutions come through which attempt to cater for any loop scenario.

I have actually seen this sort of issue happen in the real world. The most common place you see things like this (in my experience) is where code is attempting to manage one or more “free lists” where the nodes can switch between the lists.

Example: You’re writing a little memory manager that is responsible for allocating a block of memory which can be used by a collection of objects, let’s say of type T. On start-up, the memory manager allocates a chunk of memory to allow for the use of up to N lots of T at any given time, and it manages that chunk of memory using two separate free lists. At the start, the “allocated” list is empty, and the “unallocated” list has all the nodes in it. As the program continues to execute, and calling objects request allocation of memory for type T, the memory allocator simply removes a node from the “unallocated” list to the “allocated” list (by switching a few pointers around), and returns a reference to the newly “allocated” instance of T for the caller to use. Depending on how good (or bad :)) the author of this memory manager was, issues such as loops in the list can unfortunately become a reality. In this scenario, it is possible, through incorrect ordering of steps or bad management of pointers across the two structures, that the loop can occur almost anywhere in either of the free lists.

So while this may be unlikely when, for the most part, there are already a bunch of implementations of lists that people use day in day out it can actually appear in the wild. The purpose of the question was to attempt to come up with a way of determining if a list contains such a loop. I see it more as a debugging utility than anything else.

You’re entitled to get pedantic That’s what this is about! I think your posts are interesting, and in the case where an official “singly linked-list” (or is it “singularly”?) becomes an official “circular linked-list”, your solution would indeed be fastest. Of course, in the case where we don’t exactly know where the loop in the list occurs, this wouldn’t give us the result we’re looking for, and this is where Keith’s solution shines.

Thanks for the posts guys

So, let’s assuming we don’t have a list managing structure; we simply have items in memory that point to their successor and have no choice but to traverse the list to examine whether or not it is null terminated.

The solution posted by Keef in that respect then is horribly inefficient since you can’t actually traverse the list at different speeds at all; each node only knows about its successor. So, the ‘faster’ mover actually has to read a node and check the successor twice for each one check made by the slower mover. It’s late here and I don’t want to do the math but you will end up traversing the entire list at least 1.5 times I think.

So, the simplest solution is (since you know the first element of the list – you’ve got to start somewhere) is to simply sequentially move through the list until a successor is null (it’s a singly linked list) or you get back at the start. The most you would traverse then, assuming you start at the very first node, is once, and you’d check each node just once, rather than 3 times (the slow mover checking each node, and the fast mover checking each node and the successor node in order to leap ahead).

So, let’s assuming we don’t have a list managing structure; we simply have items in memory that point to their successor and have no choice but to traverse the list to examine whether or not it is null terminated.

The solution posted by Keef in that respect then is horribly inefficient since you can’t actually traverse the list at different speeds at all; each node only knows about its successor. So, the ‘faster’ mover actually has to read a node and check the successor twice for each one check made by the slower mover. It’s late here and I don’t want to do the math but you will end up traversing the entire list at least 1.5 times I think.

So, the simplest solution is (since you know the first element of the list – you’ve got to start somewhere) is to simply sequentially move through the list until a successor is null (it’s a singly linked list) or you get back at the start. The most you would traverse then, assuming you start at the very first node, is once, and you’d check each node just once, rather than 3 times (the slow mover checking each node, and the fast mover checking each node and the successor node in order to leap ahead).

A classic singly linked list (one which tracks only the first entry in the list, with each node knowing only the node that follows) is limited in usefulness in terms of adding new items; unless you want to walk sequentially through the entire list to find the last and update its ‘next’ pointer, you are limited to only adding items to the front of the list. The class or construct managing the list would then be responsible for updating the ‘next’ pointer of this new item to point to that which was previously first. In that respect, if the class implementing the linked list is properly implemented, it woudl be impossible to have the list become circular surely? (consumers of the list rely on the list to manage itself). The list is merely an organisational representation of data, and thus the consumer or producer of the data would not ever be concerned with the semantics of the list’s own pointers.

Similarly, a circular singly linked list would be implemented in such a way that two pointers are updated on the addition of a new entry; the next pointer of the last item, and the next pointer of the new item. Such a construct would by nature of its design have to manage the circular link (but as Knuth points out there are problems to be aware of when managing a circular singly linked list that could be empty – pg274).

So, the upshot from a design standpoint is that if there is a risk that your singly linked list has in fact become circular, giving rise to the need to write code to determine if that’s the case, then surely refactoring driven by tests to implement an effective list-structure-manager construct would be the best way forward to not only address the potential bug, but also shore up the architecture of the solution at hand.

A classic singly linked list (one which tracks only the first entry in the list, with each node knowing only the node that follows) is limited in usefulness in terms of adding new items; unless you want to walk sequentially through the entire list to find the last and update its ‘next’ pointer, you are limited to only adding items to the front of the list. The class or construct managing the list would then be responsible for updating the ‘next’ pointer of this new item to point to that which was previously first. In that respect, if the class implementing the linked list is properly implemented, it woudl be impossible to have the list become circular surely? (consumers of the list rely on the list to manage itself). The list is merely an organisational representation of data, and thus the consumer or producer of the data would not ever be concerned with the semantics of the list’s own pointers.

Similarly, a circular singly linked list would be implemented in such a way that two pointers are updated on the addition of a new entry; the next pointer of the last item, and the next pointer of the new item. Such a construct would by nature of its design have to manage the circular link (but as Knuth points out there are problems to be aware of when managing a circular singly linked list that could be empty – pg274).

So, the upshot from a design standpoint is that if there is a risk that your singly linked list has in fact become circular, giving rise to the need to write code to determine if that’s the case, then surely refactoring driven by tests to implement an effective list-structure-manager construct would be the best way forward to not only address the potential bug, but also shore up the architecture of the solution at hand.