Hi Alex,

Referring to PR #48, I have added two traits:

• Sort
• SortMutable

in an attempt to unify the sorting algorithms behind structs that expose the sort method.

Not sure how complete the feature needs to be, but I believe the PR would be too large at that point to be easily reviewable. I was considering submitting the traits for 1 algorithm at a time, modifying those that do not adhere to the trait properties.

I wanted to get into contributing to OSS, and I thought your library would be a great place to start. Any comments are welcome.

These were really easy to add, they're functionally identical to the ones in the older repository, the only thing I changed was proper tests for reverse (it only had palindromes) and morse, which never attempted decoding.

What does this PR do?

Added the following ciphers and string manipulation algorithms:

• Reverse
• Morse
• VIgenere

All Submissions:

• [x] Have you followed the guidelines in our Contributing document?
• [x] Have you checked to ensure there aren't other open Pull Requests for the same update/change?

New Feature Submissions:

1. [x] Does your submission pass tests?
2. [x] Have you lint your code locally prior to submission?

There were a few algorithms I wasn't able to do this for, because the function signatures didn't match those expected by the macro. Perhaps it'd be a good idea to standardize those too?

#7

More or less just copied any files that wouldn't cause an overwrite, and updated use statements of various modules accordingly.

Made a few tweaks to searching::kth_smallest_heap as it relied on a different version of the Heap struct, and made sorting::quick_sort::partion public as searching::kth_smallest depended on it.

I also took the liberty to rename string_matching into just string like in the old repo, as there are a few algorithms that aren't strictly related to matching.

This is pretty much my first time contributing to anything. I just came across the issue and thought "move some stuff around? I can do that!" (one of these days I might try my luck contributing some actual code). Please let me know if there's anything I missed or should've done differently.

Hi, hope these comments are okay. I didn't change it with this commit but I did notice that in the src/data_structures/README.md that the Properties section for the linked list stack says that accessing the tail happens in O(n) time. This doesn't seem particularly relevant to stacks, though?

The current implementation of Counting Sort supports sorting integers only, but it can be extended to support any form of object that is represented by an integer key.

Also, the current implementation is missing tests for stability. Since radix sort relies on this algorithms' property of being stable, it would be nice to assert that it is present.

• Extend Counting Sort to the general case of having objects with integer keys.
• Add tests that assert the stability of the algorithm.

• Implementing the MutableSorter trait for CombSorter
• Standardized the tests by adding the descending test case to the macro and removing it from tests that use it

Hey, I am a junior developer and I am looking to increase my open source contributions. I found your project on Good First Issue.

I promise I won't mess anything up. Thanks for the opportunity to contribute.

In #19 has been pointed out that a new macro that represents the test suite for sorting algorithms could be used to avoid code duplication in tests for sorting algorithms.

The changes introduced by this PR are the following:

1. introduction of the sorting_tests! macro, which represents the test previously done through the basic, repeated_elements and pre_sorted functions
2. the macro can be used in two ways:
   1. sorting_tests!(sorting_function), for algorithms implemented without in-place implementation
   2. sorting_tests!(sorting_function, inplace), for algorithms with in-place implementation
3. all the implemented sorting algorithms now use the sorting_tests! with two excpetions:
   1. radix sort uses a different test suite
   2. shell sort uses only the basic test function and the pre_sorted has a different name (already_sorted in this case)

The total number of tests run with cargo test remains 129

Hi, I found some typos in the comment section of the following code and fixed it. Please merge if you like.

• src/ciphers/morse_code.rs
• src/ciphers/transposition.rs
• src/dynamic_programming/edit_distance.rs
• src/dynamic_programming/egg_dropping.rs
• src/general/nqueens.rs

Currently, we have the assert_sorted! and assert_not_sorted! macros that make it easy to check that an array is sorted. But we have very similar tests for the sorting algorithms and it makes sense because the API of those algorithms should be the same or very similar: You take an array and sort it.

Therefore, I think it makes sense to come up with a new macro that represents our test suite for sorting algorithms, and then we can extend each local module with other tests that may be relevant to a specific algorithm like counting sort not relying on items being integers.

Hi, I want to contribute to this repo, I particularly want to create some algorithms with proper documentation.

I created tower of hanoi algorithm with test cases. Thank you.

Following the discussion in https://github.com/alexfertel/rust-algorithms/pull/35 it would be good to make tests consistent across sorting algorithm implementations such that they share a basic suite (calling the sorting_tests! macro) and then any other test that might be meaningful to that particular algorithm.

Hi, I want to contribute to this repo, I particularly want to create the all searching algorithms with proper documentation.

I created a Linear Search algorithm with test cases. Thank you.

We want to document each class of algorithms. This comes in two flavors:

• Adding README files to each directory holding a class of algorithms, for example, sorting.
• Adding documentation comments to each of the algorithms.

You can find examples of documentation comments in here.

General guidelines for the explanations are to be concise and link to the bibliography. Images are better than no images. If it is possible include time and space complexities.