feat: add Levenshtein distance

[vil02]

This PR adds a dynamic programming implementation of the Levenshtein distance.

[ZoomRmc]

Thanks for your contribution!

Some general overview of the algorithm an a basic use-case in a runnableExamples block would be nice (for example, just selecting a suitable string from a "dictionary" sequence as a substitution for a string with a typo).

[dlesnoff]

Nice implementation! At certain places, I would like more comments.

You can consider adding the two-vector solution to the Levenshtein distance.
In any case, Levenshtein should be put in regard to other metrics. Hamming distance is at the basis of linear code theory and operates only by substitution. We might also add in another module in the future the Longest Common Substring sequence, which on the contrary, operates by deletion and insertion.
The Edit Distance is more general and gives weights to the three operations.

[vil02]

@dlesnoff @ZoomRmc thanks for your feedback. I need some time to fully digest it.

[dlesnoff]

Take your time!

[vil02]

You can consider adding the two-vector solution to the Levenshtein distance.

I have been thinking about that. My reasoning for not doing that is the following:

• this repository is for educational proposes,
• when someone would read this code and think "wait a second, actually only two rows are needed - one can save lots of space!" - that would have a very high educational value,
• having levenshteinDistanceRecursive, levenshteinDistanceFullMatrix and levenshteinDistanceTwoRows is an overkill in my opinion (and quite cumbersome to insert into this project because of its structure).

[ZoomRmc]

• Regarding other, more optimized solutions: it's absolutely fine to have only the basic one and leave the room for improvement in later PRs, possibly from new contributors. If it happens, we can always come to a decision where exactly to put them.

[ZoomRmc]

I think by this point it's ready to merge!

[dlesnoff]

I must decide between the Key type and the proc overloading solution but I need some additional time for this. I let @ZoomRmc decide on this if I do not react quickly which is highly probable.
I am happy with the changes but require some documentation improvements.
Dropping the more subtle two-vector implementations is fine by me.

[dlesnoff]

When someone would read this code and think: "Wait a second, actually only two rows are needed - one can save lots of space!" - that would have a very high educational value,

He would have then reinvented the wheel. No, most people would not spot this. You are right. Restraining information teaches less and educates more. Should we teach or educate?

I am more in favour of teaching. One must know a similar example to spot this kind of space savings. He has to be already knowledgeable.

Anyway, this is more suitable for another PR. I think that the implementation is neat and fine as is. I just want:

• the small documentation changes.

• the DIRECTORY.md file obtained with this command:

nim r .scripts/directory.nim > DIRECTORY.md

• A last check with nimpretty

[vil02]

As requested:

• the small documentation changes, cf. 37604c8, b437ab8, 71eaddf.
• run nim r .scripts/directory.nim > DIRECTORY.md, cf. e8bdb27
• A last check with nimpretty, cf. this log.

[dlesnoff]

Thanks a lot for this excellent contribution!
We had some fruitful conversations on different approaches, and I appreciate having some opposite views.

[vil02]

@dlesnoff @ZoomRmc thanks again for the review and fruitful discussions!