[RFC] Separate fuzziness score from sort score

[krisk]

[This is in response to #354]

Currently, the score that is exposed in search results is calculated as a function of the following:

• Internally calculated fuzziness score
• User inputted weight of the key
• Field-length norm (i.e, the shorter the field, the higher the weight)

Using the above, we compute the final score, which is what is used to sort the list.

As a result, exact matches are not necessarily given a final score of 0. As noted in #354, however, people may want to use the score to decide whether a match was indeed exact.

To address this, in v5.2.2-alpha.0 I thus separated the "sort score" ($score) from the "fuzziness score" (score), of which only the latter is exposed.

I am undecided on whether I will publish this as "latest". I would love some feedback.

[krisk]

cc: @acnebs @MadsMadsDk @laurentiustroia

[connebs]

Fair enough that the score is getting a little bit more sophisticated.

For my purposes, an option like includeExact which then adds exact: true to the result objects (if it is indeed a strict equality match) could work if you would like this to be separate from the score.

I generally preferred the score method though, as it was fairly intuitive that 0 is an exact match and it means fewer properties on the result objects.

[laurentiustroia]

In my opinion, added a new feature like includeExact sound good, but this can be redundant to have also includeScore where the 0 mean perfect match.

Also, can we update the documentation and fusejs.io for option includeScore when is exact match the number tends to 0 instead of when exact match are 0 ?

[MadsMadsDk]

I think the underlying issue here is, that for developers who aren't necessarily math savvy (like myself), it makes sense to look for scores equal to 0, and interpret those as exact matches, and not compare to a number expressed as an exponential notation. I initially interpreted that as a bug, until I found this issue.

However, I understand that a score of 0.0023545343451325 does not necessarily qualify as an exact match.

I like the includeExact solution, and are happy to go with that. I also have a suggestion that expands upon that concept.

Would it make sense to introduce an exactMatchTreshold to the fuzzy matching options? That would allow developers to set their own tresholds for when they consider a score close enough to be an exact match for their use case. If the score falls below that treshold, it would return a score of 0.

This way, you have the option to keep using score as the preferred way of finding exact matches, and also flag your result items with an exact: true boolean if you like.

[danielfdickinson]

I will try and look at this implementation soon-ish (heavy on the 'ish' probably), but I think keeping the sort score separate from fuzziness is a really good idea.

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days