Mailing-List: contact lucene-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Lucene Developers List" <lucene-dev@jakarta.apache.org>
Subject: TermInfosReader.getIndexOffset javadoc and code inconsistent?
From: Nigel Tao <ntao@panscient.com>
Reply-To: ntao@panscient.com
To: Lucene Developers List <lucene-dev@jakarta.apache.org>
Content-Type: text/plain
Message-Id: <1085019974.4081.12.camel@vitabrits.panscient.com>
Mime-Version: 1.0
Date: Thu, 20 May 2004 12:26:15 +1000
Content-Transfer-Encoding: 7bit

This is a minor quibble, but are the javadocs and the code for
TermInfosReader.getIndexOffset(Term) inconsistent?  The javadocs say
"less than" but the code says "less than or equal to" (if the "return
mid" route is taken, which requires that term.compareTo(indexTerms[mid])
== 0).

But more importantly - does this impact any consumers of this method -
if, for example, they actually presume "less than" rather than "less
than or equal to"?

Also, this may be a strictly academic point, but should it be documented
that this method may return -1 if no index entry is <= term?  In
practice this is impossible since indexTerms[0] is always the empty Term
with "" field and "" text, which is less than (or equal to :-) any other
Term.

cheers,
Nigel.


-----------------------------------
/**
 * Returns the offset of the greatest index entry which is
 * less than term.
 */
private final int getIndexOffset(Term term) throws IOException
{
	// binary search indexTerms[]
	int lo = 0;
	int hi = indexTerms.length - 1;

	while (hi >= lo)
	{
		int mid = (lo + hi) >> 1;
		int delta = term.compareTo(indexTerms[mid]);
		if (delta < 0)
			hi = mid - 1;
		else if (delta > 0)
			lo = mid + 1;
		else
			return mid;
	}
	return hi;
}
-----------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-dev-help@jakarta.apache.org