-
Notifications
You must be signed in to change notification settings - Fork 15
linked list #24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
linked list #24
Changes from all commits
Commits
Show all changes
14 commits
Select commit
Hold shift + click to select a range
d307367
docs: readme for linkedlist
yeoshuheng 2abbf00
docs: fixed readme typo
yeoshuheng 5607eef
docs: fix skiplist section
yeoshuheng fff8d01
feat: added notes, changed jdocs, reordered funcs
yeoshuheng a34bce5
docs: reformat png
yeoshuheng d884d59
refactor: remove dir
yeoshuheng 69432d4
feat: junit test for ll
yeoshuheng 41bc522
fix: error in test
yeoshuheng 7379cae
refactor: shifted to legacy
yeoshuheng 5e58a95
docs: update README.md
yeoshuheng 784e270
docs: update README.md
yeoshuheng df8e80e
docs: edited javadocs based on review
yeoshuheng 90eb119
docs: remove search, insert ops
yeoshuheng a73908f
docs: added dbl linkedlist + refactored layout
yeoshuheng File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,84 @@ | ||
# Linked Lists | ||
Linked lists are a linear structure used to store data elements. | ||
It consists of a collection of objects, used to store our data elements, known as nodes. | ||
|
||
 | ||
|
||
*Source: GeeksForGeeks* | ||
|
||
### Linked Lists vs Arrays | ||
Linked lists are similar to arrays in | ||
terms of used and purpose, but there are considerations when deciding which structure to use. | ||
|
||
Unlike arrays, which are stored in contiguous locations in memory, | ||
linked lists are stored across memory and are connected to each other via pointers. | ||
|
||
 | ||
|
||
*Source: BeginnersBook* | ||
|
||
## Analysis | ||
Some common operations involved in a linked list includes looking up elements in a linked list and inserting elements into a linked list. | ||
|
||
Searching a linked list requires O(n) time complexity whereas inserting into a linked list from a specified index requires O(n) time complexity. | ||
|
||
## Notes / Further Details / Conclusion | ||
|
||
### Memory Requirements & Flexibility | ||
As a contiguous block of memory must be allocated for an array, its size is fixed. | ||
If we declare a array of size *n*, but only allocate *x* elements, where *x < n*, | ||
we will be left with unused, wasted memory. | ||
|
||
This waste does not occur with linked lists, which only take up memory as new elements are added. | ||
However, additional space will be used to store the pointers. | ||
|
||
As the declared size of our array is static (done at compile time), we are also given less flexibility if | ||
we end up needing to store more elements at run time. | ||
|
||
However, linked list gives us the option of adding new nodes at run time based on our requirements, | ||
allowing us to allocate memory to store items dynamically, giving us more flexibility. | ||
|
||
### Conclusion | ||
You should aim to use linked list in scenarios where you cannot predict how many elements you need to store | ||
or if you require constant time insertions to the list. | ||
|
||
However, arrays would be preferred if you already know the amount of elements you need to store ahead of time. | ||
It would also be preferred if you are conducting a lot of look up operations. | ||
|
||
## Linked List Variants | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Do mention double-linked list too. This is the most common variant after the conventional linked list, that allows popping of elements from front and back. Java's Deque (double-ended queue i believe) is essentially a double-linkedlist |
||
The lookup time within a linked list is its biggest issue. | ||
However, there are variants of linked lists designed to speed up lookup time. | ||
|
||
### Doubly Linked List | ||
|
||
 | ||
|
||
*Source: GeeksForGeeks* | ||
|
||
This is a variant of the linked list with each node containing the pointer to not just the next note, but also the previous node. | ||
|
||
Unlike the standard linked list, this allows us to traverse the list in the backwards direction too, this makes it a good data structure to use when implementing undo / redo functions. However, when implementing a doubly linked list, it is vital to ensure that you consider and maintain **both** pointers. | ||
|
||
It is also worth noting that insertion from the front and back of the linked list is a O(1) operation. (Since we now only need to change the pointers in the node.) | ||
|
||
### Skip list | ||
|
||
 | ||
|
||
*Source: Brilliant* | ||
|
||
This is a variant of a linked list with additional pointer paths that does not lead to the next node | ||
but allow you to skip through nodes in a "express pointer path" which can be user configured. | ||
If we know which nodes each express pointer path stops at, we would be able to conduct faster lookup. | ||
|
||
This would also be ideal in situations where we want to store a large amount | ||
of data which we do not need to access regularly that we are not willing to delete. | ||
|
||
### Unrolled Linked Lists | ||
|
||
 | ||
|
||
*Source: Brilliant* | ||
|
||
Unrolled linked lists stores multiple consecutive elements into a single bucket node. | ||
This allows us to avoid constantly travelling down nodes to get to the element we need. |
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is great and comprehensive! Just some restructuring as per amadeus' suggestion on standardisation.
You can follow these headers, with some room for flexibility for sub-sections within each section.
# Title
Introduction or context or commonly misunderstood stuff. Stuff to tell the reader that we know the current context and all. so yup Linked List vs Arrays is one good example.
## Analysis
Here we discuss time and space complexity of the whole algorithm. Perhaps if the algorithm has a non-trivial sub-routine, and its worth discussing more, than you can discuss how the analysis is derived here. No need to discuss implementation-specific unless necessary (though in-line comment in the code itself might better help), grab the general idea and present.
## Notes / Further Details / Conclusion
Here is an optional section to discuss further misc details that do not fit above but you believe to be crucial for students to be aware of. I think your addition of variants is one good example! You discussion on memory requirements, with linked list being a versatile structure that does not require a fixed size to be declared can put here too.
I noticed you discussed search and insert operations. I think these are not necessary and we probably should avoid making it a standard else its more workload. Only operations that are non-trivial (not easily inferred from code) should then be considered for discussion here. For linked list, i think its fine to omit since most students should be able to easily parse the logic from the code.
One last thing, for each of the ## sections, you can do what you did of segregating further into ### sub-sections if you wish.