UXSearchResult

UXSearchResult is one entry in the array UXSearchIndex.search returns.

#use <UXKit>            // or #import "UXSearchIndex.xc"

Overview

class UXSearchResult : Object {
    i32 docId;    // the id you passed to addDocument
    i32 score;    // summed term frequency
}

Array<UXSearchResult>* hits = ix.search((u8*)"quick dog");
for (u16 i = 0; i < hits.count(); i = i + 1) {
    UXSearchResult* r = (UXSearchResult* ?)hits.get(i);
    showRow(r.docId);            // best first
}

The array is already ordered best first, so nothing needs sorting afterwards.

The id is yours

i32 docId

The value you passed to addDocument: a row index, a file id, a key into your own array. The index stores only ids, never documents, so this is the only link from a hit back to what was found.

The index therefore cannot tell you that an id is stale. If rows can be deleted, check the id is still live before showing it.

The score is comparable within one search only

i32 score

The sum, over the query’s terms, of how many times each appears in that document. Bigger is better.

It is not a percentage, not normalised, and not comparable between searches. A one-word query produces small numbers and a five-word query large ones, for the same documents. Showing it to a user as a relevance figure would mislead.

Use it within one result set: for the ordering, a relative bar, or a cut-off such as “ignore anything scoring below half the top hit”.

Fields

docId

i32 docId

score

i32 score

Example

search 'dog': doc2=2 doc1=1
search 'quick dog': doc2=4 doc1=2

Doc 2 says dog twice and quick twice. Both scores grew when the query did: the same documents give different numbers, so the value only means something relative to its neighbours.

The program is website/site/examples/uxkit/records.xc. The doc-examples gate compiles it, and the block above is its output.

Conforms to

Inherits Object