change space complexity of linked list's __len__ from O(n) to O(1)

[amirsoroush]

Describe your change:

Following #5315 and #5320, I was convinced that it's better to calculate __len__ each time on demand. But current implementation has "space" complexity problem when dealing with a huge linked list. That temporary tuple is unnecessary. A one-line change using built-in sum() and a generator expression would solve it without breaking existing codes.

• Add an algorithm?
• Fix a bug or typo in an existing algorithm?
• Documentation change?

Checklist:

• I have read CONTRIBUTING.md.
• This pull request is all my own work -- I have not plagiarized.
• I know that pull requests will not be merged if they fail the automated tests.
• This PR only changes one algorithm file. To ease review, please open separate PRs for separate algorithms.
• All new Python files are placed inside an existing directory.
• All filenames are in all lowercase characters with no spaces or dashes.
• All functions and variable names follow Python naming conventions.
• All function parameters and return values are annotated with Python type hints.
• All functions have doctests that pass the automated testing.
• All new algorithms include at least one URL that points to Wikipedia or another similar explanation.
• If this pull request resolves one or more open issues then the commit message contains Fixes: #{$ISSUE_NO}.

[Cjkjvfnby]

The sum will call iter(self) inside, so this code is still O(n).

[Cjkjvfnby]

For the classical linked list, the best length is O(n).

PS. collections.deque is not a real linked list, it's a wrapper around it, so it basically counts how many append/delete methods were called. https://github.com/python/cpython/blob/main/Modules/_collectionsmodule.c#L196

https://wiki.python.org/moin/TimeComplexity

[amirsoroush]

Are you talking about "Time" complexity? This line would fix the "Space" complexity as it only fetches one item at a time and adds 1 to the final result as opposed to tuple() which loads all the items into the memory.

[Cjkjvfnby]

I missed that, you definitely right.

[cclauss]

Fun exercise... Go to https://pyodide.org/en/latest/console.html to get a current Python repl running on WASM.

Paste in the following code and hit return.

>>> from timeit import timeit
setup="from itertools import product; from string import ascii_letters"
timeit("sum(1 for _ in product(ascii_letters, repeat=4))", number=10, setup=setup)
timeit("len(tuple(product(ascii_letters, repeat=4)))", number=10, setup=setup)

5.0610000000000355
4.121999999999957

sum() is slower than len() for 7,311,616 items.

Refresh the webpage to clear out any clutter in memory...

Paste in the following code and hit return.

>>> from timeit import timeit
setup="from itertools import product; from string import ascii_letters"
timeit("sum(1 for _ in product(ascii_letters, repeat=5))", number=1, setup=setup)
timeit("len(tuple(product(ascii_letters, repeat=5)))", number=1, setup=setup)

26.686000000000035
Traceback (most recent call last):
  ...
MemoryError

sum() delivers an answer for 380,204,032 items while len() raises a MemoryError.

These numbers are for long iterators but still good to know.

[amirsoroush]

I added this change to circular_linked_list.py, doubly_linked_list.py and merge_two_lists.py files as well.