Use LCS to Rank Matches

[walles]

I suggest using LCS to rank matches:
https://en.wikipedia.org/wiki/Longest_common_subsequence_problem#Solution_for_two_sequences

Matches with lower number of substrings would come before matches with higher number of substrings.

This would be a lot more generic than the substring() based approach suggested in some PRs.

If you want to play with this, here's an online thing demonstrating the concept (I didn't write this, just found it):
http://lcs-demo.sourceforge.net/

Start by upping the "Max Size" a bit, then type in two strings and press "Execute LCS Lengths" to see how it works.

One real-world use case where this would come in handy is when searching for "git push", note how it's third place even though "git" and "push" are exact matches. Single-word matches would be caught by this as well.

[plrenaudin]

Interesting idea. Found the algo for CoffeeScript: http://rosettacode.org/wiki/Longest_common_subsequence#CoffeeScript

Will try to implement it in my PR

[jeancroy]

LCS alone will not help for the order of item in the screenshot.

We have LCS("git push","git push") = "git push"
But also LCS("git push","git plus hunk") = "git push"

What you need is to normalize matches against the length of both string. I myself have a project using LCS and use something like this:

m = Length of LCS(a,b)
lena = a.length
lenb = b.length
score = m*(m/lena+ m/lenb)

Note that you can probably use current algorithm to calculate m too. This is because current algorithm looks like a greedy approximation of LCS, with special score depending of the nature of the character.
By greedy i mean score("hzello","helloz") will match the z because it's in both sub-string but will miss the ello part doing so. LCS will skip the z to match ello

If you want to see behavior of above scoring among other things, I have a demo page

[plrenaudin]

Tried the LCS, it's way too slow.

Filtering 66672 entries for 'index' took 6557ms for 6168 results
Matching 66672 entries for 'index' took 237ms for 6168 results

Instead of

Filtering 66672 entries for 'index' took 267ms for 6168 results
Matching 66672 entries for 'index' took 218ms for 6168 results

Maybe I'm missing something...

I also added a test in my PR for the use case above.
The issue is with using 2 words: "push" retrieve the correct result (see test) but "git push" doesn't 😞

[walles]

Well spotted @jeancroy, I see now that LCS won't handle my use case.

Your scoring function can be greatly simplified into "prefer shorter hits" if used to compare already-filtered hits. Since the hits are already filtered, we actually already have the LCS, and:

• m = the length of the LCS = constant between all options
• lena = the length of the LCS = m = constant between all options
• lenb = the only thing varying = the length of the candidate string

So if we replace lena with m, we get...
score = m * (m/m + m/lenb) = m * (1 + m / lenb) = m + m^2/lenb
... and since m is the same between all candidates its value won't affect comparisons and we can just as well replace with a constant of our choosing (I choose 1)...
score = 1 * (1 + 1^2/lenb) = 1 + 1/lenb
... and since adding the same constant to all values we compare doesn't change anything we can remove that too, giving us...
score = 1 / lenb
... or in other words prefer shorter hits.

Which I think sounds just fine actually :)

[walles]

@plrenaudin, thanks for trying this and benchmarking it!

After the above discussion however I'm not sure this is actually the way to go any more, and I'm not convinced about pure substring matches either.

Real-world example, searching for install using cmd-shift-p gives me:

A substring match would put "Find And Replace: Select All" at the bottom (good), but it would also consider "uninstall", "install" and "installed" as equally good (bad).

So I'm starting to think that the way to go about this is to:

• Collect some real world use cases to support. I suggest "git push" and "install". Some people seem to want "cccn" to match "CamelCasedClassName.java" as well (I don't care personally) or "gaa" to match "Git Plus: Add All". Implementor's choice really :).
• Think of how a human would sort them.
• Write specs based on that. Make sure the specs contain the full list of hits for each use case.
• Implement something that makes all the new specs pass.

That's probably better than starting with a solution like I suggested here initially.

[plrenaudin]

You're right, People would also want to score starting substring with a higher score...

I'd like to have similar suggestion as IntelliJ or Sublime text but it would probably require to rewrite the whole scoring system.

We really need improvement on this because for projects with lots of files, the pertinence is just so bad that it's rare to have what we search for in first result.

[jeancroy]

@walles the part you simplified out is actually important for accuracy should you use LCS.
match("uni","university") should be better than match("unicorn","university")

Now I because your scoring function have a no typo policy I'd agree with your simplification.

[jeancroy]

I have put something together that I believe account for some of the issues mentioned.

1. Use special character to split query / subject into tokens. Match only token against token.
   • This will prevent to match across tokens push will not fully match plus husk. Same for directory, SomeDir will not match Awsome/David_R
2. Give bonus to prefix, applicable for each token.
   • install will match prefix for second token of git install but will not match prefix of git uninstall
3. If you are still interested in using LCS, I have attached an implementation that should be faster that what @plrenaudin tested (With also the token stuff mentioned above).

https://gist.github.com/jeancroy/a6a7f59db14de85b2b97

[plrenaudin]

@jeancroy Thanks for the idea!
I like the first point (match the tokens instead of the entire query).
Just tried to change the actual score function by your Gist but lots of tests are failling and benchamrks result is:

Filtering 66672 entries for 'index' took 1322ms for 2040 results
Matching 66672 entries for 'index' took 250ms for 2040 results
Results count changed! 2040 instead of 6168

It's missing some results so even if it worked, it would still be quite slow compared to the actual implementation.

But there is definitely a potential improvement in the tokenizing of the query / subject.

[jeancroy]

@plrenaudin can I play with your implementation of that benchmark? It should not miss an "index" so i'm curious to debug that, also query is not meant to be re-computed each time.

---

Also open question ... Why do this project score special character higher ? I mean any character of query not in subject squash the score to 0. Isn't not being squashed to 0 a good enough outcome ? Also every result not being 0 will have every char including every special char and their bonus, so it doesn't help the sort very much.

[plrenaudin]

@jeancroy My "implementation" is just to change the score function by your gist, nothing more nothing less. This is where the magic should happen and the score put the relevant results in front of the rest.

I'm sure you could improve thist but it looks like the algo has much more complexity than the one in place so having a slower benchmark is not that surprising. I personally wouldn't mind having a slower fuzzy algo for more pertinence though.

[jeancroy]

@plrenaudin sorry I did not meant you have changed something in a wrong way. Just I never played with coffeescript / node only before today so I didn't know where to start. I corrected something in my code.

Filtering 66672 entries for 'index' took 877ms for 2040 results
Matching 66672 entries for 'index' took 307ms for 2040 results
Results count changed! 2040 instead of 6168

I'm also OK with matches that are missed. I believe any token implementation (idea 1) will miss them.

index vs
./node_modules/npm/node_modules/path-is-inside/LICENSE.txt

and some more

[plrenaudin]

@jeancroy You didn't change anything in a wrong way, it just requires more changes to match the expected results of tests.
I'm eager to see it fully compliant with the tests.
When you look at the specs, most of them make sense so it is a good way to see if your algo is compatible. it just misses the tests about the "git push" query situation. (and maybe also a more complete test about CamelCase query)

It bothers me to see that for such an important feature there is so few people concerned in improving it.

[thomasjo]

@plrenaudin This issue has many "lurkers", I assure you. But I guess many, like myself, are very busy with other stuff. Wish I had time to invest in improving this...