Show HN: A fast, hopefully accurate, fuzzy matching library written in Go
1–10 of 32 posts
Re: Show HN: A fast, hopefully accurate, fuzzy matching library written in Go
#2If you want to make it really fast you could steal some ideas from: https://wincent.com/blog/optimization (tales of many years of optimizing a fuzzy search implementation).
Re: Show HN: A fast, hopefully accurate, fuzzy matching library written in Go
#3Hopefully accurate?
You should probably write some tests to ascertain that.
Re: Show HN: A fast, hopefully accurate, fuzzy matching library written in Go
#4Hopefully accurate? You should probably write some tests to ascertain that.
I've found it hard to write tests (though there are a few here - https://github.com/sahilm/fuzzy/blob/master/fuzzy_test.go ). Match quality is often subjective. Tweaking one parameter messes with others.
This library came out of a project I started. The project never saw the light of day. If I do see real world use, it'll be easier to find bugs and fix them :)
Re: Show HN: A fast, hopefully accurate, fuzzy matching library written in Go
#5If you want to make it really fast you could steal some ideas from: https://wincent.com/blog/optimization (tales of many years of optimizing a fuzzy search implementation).
Thanks for writing command-T :)
Let me pull up some embarrassing numbers of fuzzy matching on all of Chromium.
Re: Show HN: A fast, hopefully accurate, fuzzy matching library written in Go
#6Hopefully accurate? You should probably write some tests to ascertain that.
I've found it hard to write tests (though there are a few here - https://github.com/sahilm/fuzzy/blob/master/fuzzy_test.go ). Match quality is often subjective. Tweaking one parameter messes with others. This library came out of a project I started. The project never saw the light of day. If I do see real world use, it'll be easier to find bugs and fix them :)
No tests makes it impossible to add it to real world projects IMO
Re: Show HN: A fast, hopefully accurate, fuzzy matching library written in Go
#7Earlier quoted context omitted.
I've found it hard to write tests (though there are a few here - https://github.com/sahilm/fuzzy/blob/master/fuzzy_test.go ). Match quality is often subjective. Tweaking one parameter messes with others. This library came out of a project I started. The project never saw the light of day. If I do see real world use, it'll be easier to find bugs and fix them :)
No tests makes it impossible to add it to real world projects IMO
There are tests.
Re: Show HN: A fast, hopefully accurate, fuzzy matching library written in Go
#8Hopefully accurate? You should probably write some tests to ascertain that.
That sounds to me like a great starting point for others to contribute code. :P
Can't we all just be happy that someone decided to write a fun project and made it freely available for others to learn from?
Re: Show HN: A fast, hopefully accurate, fuzzy matching library written in Go
#9Made a PR to switch to runes for iteration. Runes are canonical in Go for unicode codepoints and also have no memory allocation, so they're wicked fast! More importantly they make the code compatible with unicode names.
You can also save on a ton of allocation if you reuse unleaked position slices on each match. It may also be nice to have a maxMatches argument that lets users set a limit, which would save on unnecessary allocation.
Re: Show HN: A fast, hopefully accurate, fuzzy matching library written in Go
#10Have you tried out one of the standard 'distance' metrics like Hamming distance or Levenstein distance? This would at least give you an objective measure of success. Whether that's something that actually works for what you're trying to achieve is of course an open question, but both Hamming distance matching and Levenstein distance matching (the latter is harder but probably better for your purposes) are very well understood.