Hi, I had a quick look and it seems that Anna is right, but there should be
a case where you ask to rerank more documents than what you want to see..
need to review the code :)
cheers,
Diego
On Thu, 2 Dec 2021, 16:40 Alessandro Benedetti, <a.benede...@sease.io>
wrote:
> Adding Christine and Diego to the loop if they missed this.
> Thanks Anna for raising.
>
> Cheers
> --------------------------
> Alessandro Benedetti
> Apache Lucene/Solr Committer
> Director, R&D Software Engineer, Search Consultant
>
> www.sease.io
>
>
> On Wed, 10 Nov 2021 at 16:41, Anna Ruggero <a.rugg...@sease.io> wrote:
>
>> Hi all,
>>
>> I was looking at the *org.apache.solr.ltr.LTRRescorer#scoreFeatures *
>> method.
>> Since we are using reranking applied to some topN documents (rerankDocs
>> parameter) I think that this block of code in
>> *org.apache.solr.ltr.LTRRescorer#scoreSingleHit
>> *will never be accessed:
>>
>> if (hitUpto >= topN) {
>> // once that heap is ready, if the score of this document is lower that
>> // the minimum
>> // i don't want to log the feature. Otherwise I replace it with the
>> // minimum and fix the
>> // heap.
>> if (hit.score > reranked[0].score) {
>> reranked[0] = hit;
>> heapAdjust(reranked, topN, 0);
>> if (featureLogger != null && indexSearcher instanceof SolrIndexSearcher)
>> {
>> featureLogger.log(hit.doc, rerankingQuery, (SolrIndexSearcher)
>> indexSearcher,
>> modelWeight.getFeaturesInfo());
>> }
>> }
>>
>> Since we are reranking the topN documents. the *hits.length* in the
>> scoreFeatures method is always *equal* to the *topN* variable.
>> Therefore, since *hitUpto* is going from *0* to *hits.length -1*, we
>> will never have *hitUpto >= topN*
>>
>> Is there any condition I am missing?
>> Couldn't this piece of code be removed?
>>
>> Thank you,
>> Anna
>>
>
