5 ms·

So it's a "string contains string" function in Javascript? I mean, that's great, and this seems like a simple and clean implementation, but is it really worthy

by acbart 12y ago

So it's a "string contains string" function in Javascript? I mean, that's great, and this seems like a simple and clean implementation, but is it really worthy of a hacker news post? It seems like the answer to a stack overflow question.

sync 12y ago
Based on the first example, it seems a wee bit more complicated than that: fuzzysearch('twl', 'cartwheel') // <- true The string 'cartwheel' does not contain the string 'twl' directly.
- bshimmin 12y ago
  I think new RegExp("twl".split("").join("(.+)?")).test("cartwheel") does approximately the same, no?
  - Guillaume86 12y ago
    Yes it's the same according to the source. You can also use ".*" to replace "(.+)?" in your regex.
    - mistercow 12y ago
      It's only the same as long as your search string doesn't contain any special characters as far as regex is concerned.
      - Guillaume86 12y ago
        Yes good catch. It's going to be a lot slower anyway. Still does a good job at explaining the matching algorithm concisely.
  - solox3 12y ago
    I guess fuzzy search also allows for substitutions like "csrtwheel", but neither you nor the OP does this.
    - kelseyfrancis 12y ago
      Yeah, anyone thinking of using this should probably instead just look for an existing implementation of something like the Damerau–Levenshtein distance.
      - logicallee 12y ago
        >anyone thinking of using this should probably instead just look for an existing implementation of something like the Damerau–Levenshtein distance. "anyone" with over 400 bytes, you mean.
      - jgalt212 12y ago
        I don't know how computationally intensive OP's algo is, but I've found that in real world use cases Damerau–Levenshtein distance algo has slowed down a number of our jobs (and we aim to avoid it is possible). Our jobs are real-time where the user is awaiting a response. So probably not limiting factor for jobs that can be run on your own time.
      - bevacqua 12y ago
        OP here. My code is meant to be used for client-side bursty usage (like filtering results for an autocomplete list), which demands the code to be quick and small. In this use case, it's not necessary to figure out how similar strings are, because it's completely irrelevant. If you're building your own search engine, which you probably shouldn't, I'd look elsewhere.
        magoon 12y ago
        > If you're building your own search engine, which you probably shouldn't, I'd look elsewhere. Advice not taken.
        kelseyfrancis 12y ago
  - bevacqua 12y ago
    Except egrigiously slower https://github.com/bevacqua/fuzzysearch/pull/6#issuecomment-77263900 https://github.com/bevacqua/fuzzysearch/pull/6#issuecomment-...

by acbart 12y ago

sync 12y ago

Based on the first example, it seems a wee bit more complicated than that: fuzzysearch('twl', 'cartwheel') // <- true The string 'cartwheel' does not contain the string 'twl' directly.

bshimmin 12y ago
I think new RegExp("twl".split("").join("(.+)?")).test("cartwheel") does approximately the same, no?
- Guillaume86 12y ago
  Yes it's the same according to the source. You can also use ".*" to replace "(.+)?" in your regex.
  - mistercow 12y ago
    It's only the same as long as your search string doesn't contain any special characters as far as regex is concerned.
    - Guillaume86 12y ago
      Yes good catch. It's going to be a lot slower anyway. Still does a good job at explaining the matching algorithm concisely.
- solox3 12y ago
  I guess fuzzy search also allows for substitutions like "csrtwheel", but neither you nor the OP does this.
  - kelseyfrancis 12y ago
    Yeah, anyone thinking of using this should probably instead just look for an existing implementation of something like the Damerau–Levenshtein distance.
    - logicallee 12y ago
      >anyone thinking of using this should probably instead just look for an existing implementation of something like the Damerau–Levenshtein distance. "anyone" with over 400 bytes, you mean.
    - jgalt212 12y ago
      I don't know how computationally intensive OP's algo is, but I've found that in real world use cases Damerau–Levenshtein distance algo has slowed down a number of our jobs (and we aim to avoid it is possible). Our jobs are real-time where the user is awaiting a response. So probably not limiting factor for jobs that can be run on your own time.
    - bevacqua 12y ago
      OP here. My code is meant to be used for client-side bursty usage (like filtering results for an autocomplete list), which demands the code to be quick and small. In this use case, it's not necessary to figure out how similar strings are, because it's completely irrelevant. If you're building your own search engine, which you probably shouldn't, I'd look elsewhere.
      - magoon 12y ago
        > If you're building your own search engine, which you probably shouldn't, I'd look elsewhere. Advice not taken.
      - kelseyfrancis 12y ago
- bevacqua 12y ago
  Except egrigiously slower https://github.com/bevacqua/fuzzysearch/pull/6#issuecomment-77263900 https://github.com/bevacqua/fuzzysearch/pull/6#issuecomment-...