You are viewing an historical archive of past issues. Please report new issues to the appropriate project issue tracker on GitHub.

Feature request #1869: Investigate pre-processing as a means of speeding up matching algorithm

Kind feature request
Product Command-T
When Created , updated
Status closed
Reporter Greg Hurrell
Tags no tags

Description

I wonder if there's an example of up-front processing that we could do which would make subsequent traversal of the path graph faster, resulting in faster scoring and matching.

Right now we don't have any "index" as such; just the list of paths. I wonder if there is some data structure (eg. a trie, or a tree; or even something more exotic involving bloom filters) together with algorithmic changes, that could give us a speed-up.

When I wrote the matching algorithm I just built it intuitively, but there is a body of research out there on fuzzy text matching and string searching which might be very useful. (Not sure how fuzzy we want to go, but imagine if the matching algorithm returned "near-misses" as well, like a spelling suggester.)

Comments

  1. Greg Hurrell

    This is probably a duplicate of issue #1828, so I'm going to close this one.

  2. Greg Hurrell

    Status changed:

    • From: new
    • To: closed
Add a comment

Comments are now closed for this issue.

Menu