Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Exact matches should have a (slightly) higher score #10

Closed
ssured opened this issue Mar 6, 2013 · 5 comments
Closed

Exact matches should have a (slightly) higher score #10

ssured opened this issue Mar 6, 2013 · 5 comments

Comments

@ssured
Copy link

ssured commented Mar 6, 2013

Thanks for this great project!

Currently searching 'hand' in a set of 'hand' and 'handsome' returns both with the same score. Obviously 'hand' should have a higher score than 'handsome'

To test:

testIndex = lunr(function(){this.field('name'); this.ref('id');});
testIndex.add({id:'hs',name:'handsome'});
testIndex.add({id:'hd',name:'hand'});
testIndex.search('hand');

results in

[   Object
    ref: "hd"
    score: 0.7071067811865476
, 
    Object
    ref: "hs"
    score: 0.7071067811865476
]
@ssured
Copy link
Author

ssured commented Mar 6, 2013

A possible solution here could be to sort equal scores to the shortest data set first, longest data set last. This way short texts have a slight preference over longer texts

@olivernn
Copy link
Owner

olivernn commented Mar 7, 2013

Yes, by default lunr is doing a prefix search for your search term, currently the terms that are returned from expanding a query are given exactly the same weighting as the terms that were in the original query.

What I think should happen is that, any term that is in the original query should be given a boost so that it contributes more to the resulting similarity score than the query terms that are part of the query expansion.

I'll have a look at the best way to implement this and let you know when I have something worth trying out.

@ssured
Copy link
Author

ssured commented Mar 8, 2013

Thanks for looking into this. I think it will make the perception of the quality of results a lot higher!

@olivernn
Copy link
Owner

olivernn commented Mar 8, 2013

I've just pushed a new version, 0.2.2, which includes a fix for this.

@olivernn olivernn closed this as completed Mar 8, 2013
@ssured
Copy link
Author

ssured commented Mar 8, 2013

Works like a charm! Great!

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants