Trying to see the rationale
halukkaramete opened this issue · comments
You have an outstanding library. Im curious to know if there is a rationale in the following scenario.
Please take a look at this screenshot.
Why do you think the much closer matches ( entries containing "audio" word ) are all beaten by a not-so-close match?
What property or the logic in your algorithm is causing the following 4 entries to score better?
I'm asking this only because there may be merits in doing so, that I fail to see. And If there are ways to tell the engine to use a different algorithm to value what I'm suggesting more..
It seems to me that if your highlights end up turning almost the entire word into red word ( as in these examples below )
should definitely beat those that are far from that "redness".
What we perceive as a human beings should also be taught to the algorithm by comparing things like the density of the highlights, (the closeness of the red letters which is a function of the number of consecutive red letters). Simply put, if we compare the consecutive red-letter counts to the overall entry word count, the more dense highlights should rise to the top.
I'd like to hear your valuable opinions on this.
this is very much intended
the scoring algo has the concept of strict matches vs bad matches
Audio is considered a bad match because d isn't a BeginningCharacter
AppDataIO is considered a strict match because of the casing
although your example does actually seem like an issue. because those strict match results are requiring a transpose from options.allowTypo. maybe the typo penalty needs to be more severe. if you set allowTypo to false you'll get the results you expect
@farzher would be great to have your input here please: home-assistant/frontend#12590
fixed in v2.0.0