Is your feature request related to a problem? Please describe. In some scenarios (e.g. finding a max, initializing graph vertex priorities in Dijkstra's, priority queue insertion) users may want to make use of positive or negative infinity. This also appears in the Cormen textbook. Users may also want to make use of the floor and ceiling mathematical operations.

Describe the solution you'd like I think a new module should be added to the library that includes (positive) infinity as a constant and implementations of the floor and ceiling operations. I believe the module should be named something like utilities or miscellaneous.

Describe alternatives you've considered Currently, when building the starter code for a problem set, the math module is imported or an infinity constant is added in the instance where it is known they would be used. However, to allow users to have these capabilities available in any Cormen Lib code they write, these capabilities should be added to the package. This will provide a better Python implementation of the pseudocode used in the Cormen textbook. I believe these capabilities should be added in a new module in the package as they do not belong in any of the existing modules. I do not believe the new module should be called math because additional functions or constants could be added to it (e.g. functions operating on strings).

Additional context

I updated dalpy_to_string to specify the object name for the following dalpy data structures:

1. Array
2. Array2D
3. Queue
4. Stack
5. Set
6. BinaryTreeNode
7. NaryTreeNode

, and added corresponding tests to test_utils_tests.

Please review my request.

Describe the bug The GraphEdgeError class does not produce a readable output. This is because the vertices are not displayed properly with their data. An example output:

dalpy.graphs.GraphEdgeError: graph does not have an edge from a vertex with name <dalpy.graphs.Vertex object at 0x7faa24830340> to a vertex with name <dalpy.graphs.Vertex object at 0x7faa24833670>

To Reproduce Steps to reproduce the behavior:

1. g = Graph()
2. v1 = Vertex("a")
3. v2 = Vertex("b")
4. g.add_vertex(v1)
5. g.add_vertex(v2)
6. g.weight(v2, v1)
7. Observe the error message.

Expected behavior The output should display the Vertex objects using the data of the vertex.

Is your feature request related to a problem? Please describe. Currently, PriorityQueue is backed by a sorted list. Therefore, the actual runtimes of DALPy PriorityQueue functions is misaligned with their assumed runtimes.

Describe the solution you'd like PriorityQueue should be reimplemented using Python's base library heapq with a custom decrease_key function that mantains O(log(n)) runtime.

Is your feature request related to a problem? Please describe. Currently there is no way to iterate over the keys of a HashTable.

Also, I believe that Set should operate more like a mathematical set versus a Java/Python set. That is, modification to the Set should be done via difference and union operations with other Sets.

Describe the solution you'd like One should be able to get either get the keys (have HashTable have a function that returns a collection of them) or be able to iterate over the keys (e.g. for k in t).

In regard to Set, add() should be removed and replace with union() which takes a Set. That way, Set will operate more how you would use it in pseudocode:

S = S U {1}
T = T - {2}
S = S U T

Describe alternatives you've considered To iterate over a HashTable now, the keys must be stored in an external data structure like an Array or Set. I also think it is best that iteration is kept to over keys to avoid confusion with tuples (like the behavior of Python dict's items()).

For Sets the alternative is to keep add() (and possible inclue a remove()) but those operate on single elements. Since singleton Sets can be easily created, I think it is suitable to use union and difference operations in their place.

Additional context None

Is your feature request related to a problem? Please describe. Yes it is a problem. I was installing cormen-lib today and found my code not working at all. The import cormen_lib statement threw an ModuleNotFoundError to me which led me to troubleshoot on my Python installation. After 20 minutes of configuring and reinstalling cormen-lib and Python and even my IDE back and forth, I finally saw your PyPI page and realized that the project was renamed.

Describe the solution you'd like Giving clear hints of the renaming is much better, instead of removing all the code under the name cormen_lib and throwing ModuleNotFoundError. We could have a print statement in cormen_lib.py: print('cormen_lib is renamed to dalpy. See https://github.com/DALPy-Developers/DALPy for detail'), as well as all the names of the classes in the library. When users try to import something from cormen_lib (e.g. running their previous homework), they would know what to do to solve it.

Describe the bug Stack equality using cormen_equals has a bug. The __stack_equals method uses copy_stack from factory_utils which does not properly copy a stack's contents, and always throws an error stating that "one can not pop from an empty stack" unless the input stack is empty.

To Reproduce Steps to reproduce the behavior:

1. Create a Stack with more than one element.
2. Call cormen_equals on that Stack with itself.
3. See error

Expected behavior The cormen_equals method should return true if the contents of the Stacks are equal and false otherwise.

Solution See line 43 of the factory_utils module - it should store s.pop() in a variable and push it to the buf Stack twice.

Is your feature request related to a problem? Please describe. For problems that require students to write functions, we sometimes want to impose that the students' functions should not modify some or all of their arguments. To currently enforce this, a copy needs to be made of the arguments that aren't meant to be modified before running the students' function. Then, after the function is run, the copy needs to be compared to the arguments that were passed to the function. This occurs in cases where the arguments are data structures of some kind (e.g. Array, Stack, etc.).

Describe the solution you'd like Since this process is easily generalizable, I believe that this should be added to the testing utilities. In particular, it could be added to the run_generic_test function.

The first question is how the user should specify which arguments should be checked for modification. This could be specified in a parameter enforce_no_mod:

• By default, enforce_no_mod is False indicating that all of the arguments can be modified.
• If enforce_no_mod is True, then none of the arguments can be modified and should all be checked.
• Lastly, enforce_no_mod can be a list of bool of equal length to the existing params parameter. enforce_no_mod[i] = True means params[i] should be checked for modification. enforce_no_mod[i] = False means that it should not.

The second question is how run_generic_test will know how to copy any arguments that need to be checked. This can be specified by a list copy_fns such that copy_fns[i] is a function that can be used to make a copy of params[i]. Since params can be a single value (i.e. not a list), it may be good to allow copy_fns to be a single function also. This should be provided a default value as to not have to change existing testing code (None is sufficient).

The third question is how run_generic_test will know how to compare the argument passed to the students' function and its copy. This also can be specified by a parameter copy_eqs_fns that operates in a similar manner to copy_fns except where copy_eqs_fns[i], in the instance it's a list, is a function that checks the equality of params[i] to its copy. This should be provided a default value as to not have to change existing testing code (None is sufficient).

Describe alternatives you've considered The alternative is the current process described in my answer to the first prompt.

Additional context

Is your feature request related to a problem? Please describe. Some problems may take a data structure as input, passed by reference, to be updated by a function implemented by a student. In these situations, test_utils.run_generic_test offers an optional parameter in_place that if set to True causes the test case to compare the expected against the input parameter. Any returned value from the tested function will then get discarded, which can cause confusion for students who believe that the function should have a return type.

Describe the solution you'd like In the case that a student has a function return a non-None value when the in_place flag is set to True, a warning could appear to indicate to the student that they should be updating the input parameter by reference instead of returning a new value. Another option could be to allow for the distinction between a "return comparator" and "parameter comparator", which both need to be satisfied. This could also be used for the dual purpose of ensuring that an input data structure is not altered when it should not be (for example the accidental destruction of a queue).

Describe alternatives you've considered The only way to clarify this at the moment is to add a note to the problem description (in English) explaining that the input should be updated, and no return type is required for such problems.

Additional context Reported by a student in Brandeis University COSI21a of Spring 2022

1. Updated GraphEdgeError class: used get_name() in the output string to produce a readable output and updated its documentation.
2. Added test_GraphEdgeError() to graph_tests.
3. Slightly modified GraphVertexError class: added " " to the name of the vertex in the output string.

removed assume runtimes, replaced with runtimes stated everywhere; updated heaps to have correct runtime; updated graphs to have O(1) edge addition; added nwe heaps test

check if we should make comment about heap insert degrading from O(logn) -> O(n) upon list resize