On Sun, Dec 6, 2009 at 5:51 PM, Uwe Schindler <u...@thetaphi.de> wrote: >> On Sun, Dec 06, 2009 at 05:31:53PM -0500, Erick Erickson wrote: >> > This may be a silly question, and I admit that I haven't looked a the >> code, >> > but was there a good reason to +1 it in the first place or was that just >> > paranoia to prevent off-by-one errors? >> >> IIRC, this implementation of the priority queue algo leaves open slot 0 to >> simplify internal calculations. It was that way when I ported 1.4.3, and >> I >> doubt that's changed. > > Thats still the same. Because calculations in heaps are simplier when > 1-based. Because of that heap[0] is unused.
Thanks for raising this Erick... it's a good question. Technically, removing the +1 would be a bug if anyone ever inserted 2B items into the PQ, but I think this is exceptionally unlikely to occur in practice. >> > If there *was* a valid reason, might it make sense to >> > +1 min(nDocs, maxDoc())? >> >> I think the patch is fine. It's really only needed to provide a more >> accurate >> error message in the event somebody specifies that they want >> Integer.MAX_VALUE >> elements, not realizing that they will be allocated up front rather than >> lazily -- they'll get an OOME rather than a NegativeArraySizeException. > > The new patch is more intelligent, it will not allocate such a big queue as > far as I have seen. It takes the numDocs() of index reader/searcher into > account. Hmm actually it takes maxDoc() into account, but it should in fact use numDocs(). I'll fix. Mike --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
