diff --git a/CONVENTIONS.md b/CONVENTIONS.md index 2a23852d..b9b50fc8 100644 --- a/CONVENTIONS.md +++ b/CONVENTIONS.md @@ -16,7 +16,7 @@ - _invariants_, and - _postconditions_ -- Use assertions to ensure preconditions, invariants and postconditions +- _Use assertions to ensure preconditions, invariants and postconditions_ > An assertion is instead a correctness condition governing the relationship between **two software modules** (not a software module and a human, or a software module and an external device). @@ -41,7 +41,7 @@ 1. Should we establish contracts between a certain function `f` and a user `U`? - - I think the answer depends on what `f` is intended to be used by, that is + - I think the answer depends (but not exclusively) on what `f` is intended to be used by, that is - if the users of `f` are intended to be programmers, then we should establish contracts - if the users of `f` are real users, then usually the real user doesn't care about the implementation of `f`, and therefore exceptions should be raised. @@ -49,8 +49,6 @@ 1. We don't know 100% sure that only a certain type of user is going to use `f`, so what should we do in these cases? - The intended clients of `f` should be one of the first things specified in the documentation of the software. **We can't protect users that do respect the rules of the software**!!! - - - In case of doubt, use exceptions. ### References @@ -62,6 +60,10 @@ - Use assertions in code **to catch implementation errors** (before releasing)!!! + - Use assertions for preconditions, invariants and postconditions. + + - Preconditions may also be explicitly stated assumptions about the inputs. + - Since these things should never happen, then in the release mode, assertions can be disable to speed up computations. @@ -74,25 +76,25 @@ ## Exceptions -- Use exceptions for something that **may** happen. +- Use exceptions for something that **may** happen - - Use exceptions to check correctness of input arguments to functions. Always??? In every case, and for every input argument??? + - Use exceptions to check correctness of input arguments to functions, if there are no assumptions about the same inputs. If there are assumptions, use assertions instead! - - The level of paranoia to check for correctness of inputs may depend on a few factors: - - - readability of the code - - - robustness of the software + - When to make assumptions??? + + - The level of paranoia to check for correctness of inputs may depend on a few factors: + + - readability of the code + + - robustness of the software - - efficiency of the software + - efficiency of the software - - cost and consequences of erroneous behaviour + - cost and consequences of erroneous behaviour - - Use exceptions to handle possible erroneous behaviour after computation + - Use exceptions to handle possible erroneous behaviour after computation?? Why??? - - Examples: division by zero .. - - - The users of `ands` are not just programmers, so use exceptions!! + - Examples: division by zero .. ?? ### References @@ -103,11 +105,6 @@ - [http://www.engr.mun.ca/~theo/Courses/sd/5895-downloads/sds-spec-1.ppt.pdf](http://www.engr.mun.ca/~theo/Courses/sd/5895-downloads/sds-spec-1.ppt.pdf) -## Assertions and Exceptions - -Since the clients intended to use `ands` are not just programmers, assertions should be used only to catch implementation errors in the _development_ phase. - -In all other cases use exceptions!!! ## Type hints diff --git a/OBJECTIVES.md b/OBJECTIVES.md index fcfed6e8..2bee8a84 100644 --- a/OBJECTIVES.md +++ b/OBJECTIVES.md @@ -9,9 +9,9 @@ - Hashing - Graphs - Trees - - Heaps - - Geometrical algorithms - - Approximation algorithms + - Heaps (e.g.: Fibonacci or binomial heaps) + - Geometrical algorithms (e.g.: convex hull) + - Approximation algorithms (e.g.: approximation-vertex-cover) - Heuristics or even to more general scientific areas diff --git a/README.md b/README.md index 7c130183..90241213 100644 --- a/README.md +++ b/README.md @@ -133,23 +133,30 @@ On the other hand, if you want to run a specific single-class test, e.g. [`test_ ## References +For each module I always try not to forget to specify the specific references that I used to implement the particular concept exposed in that module. + +Apart from those, the following are the references which I always keep an eye on. + ### Main references - [_Introduction to Algorithms_ (3rd ed.)](https://mitpress.mit.edu/books/introduction-algorithms), book by Cormen, Leiserson, Rivest, Stein - Slides provided by the professor of the course Algorithms and Data Structures, i.e. [Antonio Carzaniga](http://www.inf.usi.ch/carzaniga/) +- Slides provided by the professor of the course Algorithms and Data Structures 2, Evanthia Papadopoulou. + +- [Algorithms, 4th Edition](http://algs4.cs.princeton.edu/home/), online book by Robert Sedgewick and Kevin Wayne + - [Wikipedia](https://www.wikipedia.org/) - [Stack Overflow](http://stackoverflow.com/) -- [MIT 6.006 Introduction to Algorithms, Fall 2011](https://www.youtube.com/watch?v=HtSuA80QTyo&list=PLUl4u3cNGP61Oq3tWYp6V_F-5jb5L2iHb) -- [Interactive Python](http://interactivepython.org), website by Brad Miller and David Ranum +### Secondary references -- [Algorithms, 4th Edition](http://algs4.cs.princeton.edu/home/), online book by Robert Sedgewick and Kevin Wayne +- [MIT 6.006 Introduction to Algorithms, Fall 2011](https://www.youtube.com/watch?v=HtSuA80QTyo&list=PLUl4u3cNGP61Oq3tWYp6V_F-5jb5L2iHb) -### Secondary references +- [Interactive Python](http://interactivepython.org), website by Brad Miller and David Ranum - [Algorithms: Design and Analysis, Part 1](https://www.coursera.org/learn/algorithm-design-analysis), Coursera's course taught by Tim Roughgarden @@ -160,3 +167,14 @@ On the other hand, if you want to run a specific single-class test, e.g. [`test_ - [http://www.sanfoundry.com/](http://www.sanfoundry.com/) - [Notes on Data Structures and Programming Techniques](http://www.cs.yale.edu/homes/aspnes/classes/223/) + + +## Resources + +There many useful resources around the web to help you (and me) understand how certain algorithms or data structures work. + +One curated list that I found useful which points to a bunch of other resources is the following: + +- [https://github.com/tayllan/awesome-algorithms](https://github.com/tayllan/awesome-algorithms) + +Feel free to contribute to that list by adding other links to useful and interesting material. \ No newline at end of file diff --git a/ands/ds/TST.py b/ands/ds/TST.py index c6d79561..7c8a6bb1 100644 --- a/ands/ds/TST.py +++ b/ands/ds/TST.py @@ -120,10 +120,10 @@ def _insert(self, node: TSTNode, key: str, value: object, index: int): elif key[index] > node.key: node.right = self._insert(node.right, key, value, index) node.right.parent = node - else: # c == node.key + else: # key[index] == node.key if index < len(key) - 1: # If we're NOT at the end of the key, this is a match, - # so we recursively call search from index + 1, + # so we recursively call self._insert from index + 1, # and we move to the mid node (char) of node. # Note that the last index of the key is len(key) - 1. node.mid = self._insert(node.mid, key, value, index + 1)