Thank You! -cam On Tue, Jul 28, 2015 at 11:39 AM, Cameron Sanders via Pharo-users < pharo-users@lists.pharo.org> wrote:

---------- Forwarded message ---------- From: Cameron Sanders <camsanders@aol.com> To: Any question about pharo is welcome <pharo-users@lists.pharo.org> Cc: Date: Tue, 28 Jul 2015 11:00:11 -0400 Subject: Re: [Pharo-users] New methods for the String class What fuzzy-string matching tools & packages are available today?

-cam

On Wed, Feb 26, 2014 at 9:09 AM, Hernán Morales Durand < hernan.morales@gmail.com> wrote:

...

2014-02-26 7:10 GMT-03:00 Norbert Hartl <norbert@hartl.name>:

...

Am 26.02.2014 um 09:50 schrieb Pharo4Stef <pharo4Stef@free.fr>:

We can have an information retrieval API for aproximate string matching, i.e. Levenshtein distance (already implemented, various versions), Hamming distance, both are the most used and simplest edit distances. Then you have Longest common subsequence, Longest common substring (they are implemented in a package called "Fuzz", #longestCommonSubsequenceWith: ). Also there is the shift-or adapted for approximate matches (also implemented), fuzzy phrasing is another world also. Many applications use Damerau edit distance. Bioinformatics uses the Needleman-Wunsch and Smith-Waterman, but they call them "aligners" :) but you don't want to code the optimized version in Smalltalk, some say it could take years. All edit distances out there have specific requirements and no one is better than another for all cases. For example Jaro-Winkler is useful for one-word short strings.

I’m not sure that all these edit distances should be part of the String core api. Now what would be good is to have a chapter describing them. This chapter would work well with the bioSmalltalk one :)

I’m pretty sure they shouldn’t. Most of these are most likely for special applications. So a perfect candidate for a string extension package. A real modular entity that could load each of them individually would be perfect but we don’t have the proper tools, yet. Unless of course every of those algorithms is composed of multiple classes and would fit naturally in a package.

Absolutely for a separate package for information retrieval algorithms. From what I've seen, some algorithms require optimization through dynamic programming (automatas, matrices, etc) and that would lead to multiple classes, assuming you don't want to get dirty String class.

...

But the most important prerequisite would be to make a separate package out of it. Did I understand that right that those are part of biosmalltalk?

No. Those algorithms are spread over different packages in repositories like SqueakSource, Cincom Store, etc.

Hernán