package.html

Lucene.Net 版本源码 测试通过

    applications do not need to
    distinguish between shorter and longer documents (see <a
        href="http://www.gossamer-threads.com/lists/lucene/java-user/38967#38967">a "fair" similarity</a>).</p>

<p>To change <a href="Similarity.html">Similarity</a>, one must do so for both indexing and
    searching, and the changes must happen before
    either of these actions take place. Although in theory there is nothing stopping you from changing mid-stream, it
    just isn't well-defined what is going to happen.
</p>

<p>To make this change, implement your own <a href="Similarity.html">Similarity</a> (likely
    you'll want to simply subclass
    <a href="DefaultSimilarity.html">DefaultSimilarity</a>) and then use the new
    class by calling
    <a href="../index/IndexWriter.html#setSimilarity(Lucene.Net.Search.Similarity)">IndexWriter.setSimilarity</a>
    before indexing and
    <a href="Searcher.html#setSimilarity(Lucene.Net.Search.Similarity)">Searcher.setSimilarity</a>
    before searching.
</p>

<p>
    If you are interested in use cases for changing your similarity, see the Lucene users's mailing list at <a
        href="http://www.nabble.com/Overriding-Similarity-tf2128934.html">Overriding Similarity</a>.
    In summary, here are a few use cases:
    <ol>
        <li><p><a href="api/org/apache/lucene/misc/SweetSpotSimilarity.html">SweetSpotSimilarity</a> -- <a
                href="api/org/apache/lucene/misc/SweetSpotSimilarity.html">SweetSpotSimilarity</a> gives small increases
            as the frequency increases a small amount
            and then greater increases when you hit the "sweet spot", i.e. where you think the frequency of terms is
            more significant.</p></li>
        <li><p>Overriding tf -- In some applications, it doesn't matter what the score of a document is as long as a
            matching term occurs. In these
            cases people have overridden Similarity to return 1 from the tf() method.</p></li>
        <li><p>Changing Length Normalization -- By overriding <a
                href="Similarity.html#lengthNorm(java.lang.String,%20int)">lengthNorm</a>,
            it is possible to discount how the length of a field contributes
            to a score. In <a href="DefaultSimilarity.html">DefaultSimilarity</a>,
            lengthNorm = 1 / (numTerms in field)^0.5, but if one changes this to be
            1 / (numTerms in field), all fields will be treated
            <a href="http://www.gossamer-threads.com/lists/lucene/java-user/38967#38967">"fairly"</a>.</p></li>
    </ol>
    In general, Chris Hostetter sums it up best in saying (from <a
        href="http://www.gossamer-threads.com/lists/lucene/java-user/39125#39125">the Lucene users's mailing list</a>):
    <blockquote>[One would override the Similarity in] ... any situation where you know more about your data then just
        that
        it's "text" is a situation where it *might* make sense to to override your
        Similarity method.</blockquote>
</p>
<a name="scoring"></a>
<h2>Changing Scoring -- Expert Level</h2>

<p>Changing scoring is an expert level task, so tread carefully and be prepared to share your code if
    you want help.
</p>

<p>With the warning out of the way, it is possible to change a lot more than just the Similarity
    when it comes to scoring in Lucene. Lucene's scoring is a complex mechanism that is grounded by
    <span >three main classes</span>:
    <ol>
        <li>
            <a href="Query.html">Query</a> -- The abstract object representation of the
            user's information need.</li>
        <li>
            <a href="Weight.html">Weight</a> -- The internal interface representation of
            the user's Query, so that Query objects may be reused.</li>
        <li>
            <a href="Scorer.html">Scorer</a> -- An abstract class containing common
            functionality for scoring. Provides both scoring and explanation capabilities.</li>
    </ol>
    Details on each of these classes, and their children can be found in the subsections below.
</p>
<h4>The Query Class</h4>
    <p>In some sense, the
        <a href="Query.html">Query</a>
        class is where it all begins. Without a Query, there would be
        nothing to score. Furthermore, the Query class is the catalyst for the other scoring classes as it
        is often responsible
        for creating them or coordinating the functionality between them. The
        <a href="Query.html">Query</a> class has several methods that are important for
        derived classes:
        <ol>
            <li>createWeight(Searcher searcher) -- A
                <a href="Weight.html">Weight</a> is the internal representation of the
                Query, so each Query implementation must
                provide an implementation of Weight. See the subsection on <a
                    href="#The Weight Interface">The Weight Interface</a> below for details on implementing the Weight
                interface.</li>
            <li>rewrite(IndexReader reader) -- Rewrites queries into primitive queries. Primitive queries are:
                <a href="TermQuery.html">TermQuery</a>,
                <a href="BooleanQuery.html">BooleanQuery</a>, <span
                    >OTHERS????</span></li>
        </ol>
    </p>
<h4>The Weight Interface</h4>
    <p>The
        <a href="Weight.html">Weight</a>
        interface provides an internal representation of the Query so that it can be reused. Any
        <a href="Searcher.html">Searcher</a>
        dependent state should be stored in the Weight implementation,
        not in the Query class. The interface defines 6 methods that must be implemented:
        <ol>
            <li>
                <a href="Weight.html#getQuery()">Weight#getQuery()</a> -- Pointer to the
                Query that this Weight represents.</li>
            <li>
                <a href="Weight.html#getValue()">Weight#getValue()</a> -- The weight for
                this Query. For example, the TermQuery.TermWeight value is
                equal to the idf^2 * boost * queryNorm <!-- DOUBLE CHECK THIS --></li>
            <li>
                <a href="Weight.html#sumOfSquaredWeights()">
                    Weight#sumOfSquaredWeights()</a> -- The sum of squared weights. Tor TermQuery, this is (idf *
                boost)^2</li>
            <li>
                <a href="Weight.html#normalize(float)">
                    Weight#normalize(float)</a> -- Determine the query normalization factor. The query normalization may
                allow for comparing scores between queries.</li>
            <li>
                <a href="Weight.html#scorer(IndexReader)">
                    Weight#scorer(IndexReader)</a> -- Construct a new
                <a href="Scorer.html">Scorer</a>
                for this Weight. See
                <a href="#The Scorer Class">The Scorer Class</a>
                below for help defining a Scorer. As the name implies, the
                Scorer is responsible for doing the actual scoring of documents given the Query.
            </li>
            <li>
                <a href="Weight.html#explain(IndexReader, int)">
                    Weight#explain(IndexReader, int)</a> -- Provide a means for explaining why a given document was
                scored
                the way it was.</li>
        </ol>
    </p>
<h4>The Scorer Class</h4>
    <p>The
        <a href="Scorer.html">Scorer</a>
        abstract class provides common scoring functionality for all Scorer implementations and
        is the heart of the Lucene scoring process. The Scorer defines the following abstract methods which
        must be implemented:
        <ol>
            <li>
                <a href="Scorer.html#next()">Scorer#next()</a> -- Advances to the next
                document that matches this Query, returning true if and only
                if there is another document that matches.</li>
            <li>
                <a href="Scorer.html#doc()">Scorer#doc()</a> -- Returns the id of the
                <a href="../document/Document.html">Document</a>
                that contains the match. Is not valid until next() has been called at least once.
            </li>
            <li>
                <a href="Scorer.html#score()">Scorer#score()</a> -- Return the score of the
                current document. This value can be determined in any
                appropriate way for an application. For instance, the
                <a href="http://svn.apache.org/viewvc/lucene/java/trunk/src/java/org/apache/lucene/search/TermScorer.java?view=log">TermScorer</a>
                returns the tf * Weight.getValue() * fieldNorm.
            </li>
            <li>
                <a href="Scorer.html#skipTo(int)">Scorer#skipTo(int)</a> -- Skip ahead in
                the document matches to the document whose id is greater than
                or equal to the passed in value. In many instances, skipTo can be
                implemented more efficiently than simply looping through all the matching documents until
                the target document is identified.</li>
            <li>
                <a href="Scorer.html#explain(int)">Scorer#explain(int)</a> -- Provides
                details on why the score came about.</li>
        </ol>
    </p>
<h4>Why would I want to add my own Query?</h4>

    <p>In a nutshell, you want to add your own custom Query implementation when you think that Lucene's
        aren't appropriate for the
        task that you want to do. You might be doing some cutting edge research or you need more information
        back
        out of Lucene (similar to Doug adding SpanQuery functionality).</p>
<h4>Examples</h4>
    <p >FILL IN HERE</p>

</body>
</html>