Hi Geoffrey,
Yes, this is a caveat in the lucene contrib spellchecker which Solr uses.
>From the lucene spell checker javadocs:

* <p>As the Lucene similarity that is used to fetch the most relevant
n-grammed terms
   * is not the same as the edit distance strategy used to calculate the
best
   * matching spell-checked word from the hits that Lucene found, one
usually has
   * to retrieve a couple of numSug's in order to get the true best match.
   *
   * <p>I.e. if numSug == 1, don't count on that suggestion being the best
one.
   * Thus, you should set this value to <b>at least</b> 5 for a good
suggestion.

Therefore what you're seeing is by design. Probably we should change the
default number of suggestions when querying lucene spellchecker to 5 and
give back the top result if the user asks for only one suggestion from solr.

On Wed, Apr 23, 2008 at 5:58 PM, Geoffrey Young <[EMAIL PROTECTED]>
wrote:

> hi :)
>
> I've noticed that (with solr 1.2) the returned order (as well as the
> actual matched set) is affected by the number of matches you ask for:
>
>  q=hanna&suggestionCount=1
>    "suggestions":["Yanna"]
>
>  q=hanna&suggestionCount=2
>    "suggestions":["Manna",
>      "Yanna"]
>
>  q=hanna&suggestionCount=5
>    "suggestions":["Manna",
>      "Nanna",
>      "Sanna",
>      "Vanna",
>      "Shanna"]
>
> note how the "#1" result is completely missing from the "top 5"... or at
> least that's how I _used_ to think about the sets :)
>
> unfortunately, extendedresults seems to be a 1.3-only option, so I can't
> see what's going on here.  but I guess I'm asking if this is expected
> behavior.
>
> --Geoff
>



-- 
Regards,
Shalin Shekhar Mangar.

Reply via email to