<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Joe,<br>
I thought that renaming the jdom.jar would force a rebuild. It did
not. I took a peek on crosswire<br>
to see if I could do a clean build and you own the build and it's files
so you will have to do a clean build.<br>
By the way can you add me to the jsword group? Some jsword
directories do not have world read.<br>
As to BitwisePassage, I think it is a bit heavier than it needs to
be. It takes up lots of memory. And<br>
by and large it is a sparse array. It could stand some space
optimization. For example, only hold enough<br>
bits for the verses from the first to the last in the answer and have a
cardinal that is added to the bit position<br>
to give the verse. Subtraction would go from the verse to the bit
position. Bit operations between two<br>
BitwisePassages would be complicated by the need for normalization.<br>
If answers in a BitwisePassage were sparse between the first and
last verse, then a collection of BitSets<br>
could be used.<br>
I had thought of this earlier, but felt that there were bigger
problems to solve.<br>
Later,<br>
DM<br>
<br>
Joe Walker wrote:
<blockquote cite="mid5dd4742605013106015d38ea0b@mail.gmail.com"
type="cite">
<pre wrap="">Thanks DM, this all looks like the sensible thing to do. I've been
mulling over the PassageTally thing, but I've not worked out a reason
why it was as it was yet. I need to get my head around how it affects
best match searching properly, but since it fixes a very clear problem
it sounds good to me.
On RocketPassage - it certainly used to be the fastest; I spent some
time ages ago tweaking it to include the best of the other Passage
implementations, however since then you've fixed a few issues in
BitwisePassage (IIRC) so it may well no longer be optimal. Maybe I was
engaging in a bit of premature optimization!
Joe.
On Wed, 26 Jan 2005 21:31:09 -0500, DM Smith <a class="moz-txt-link-rfc2396E" href="mailto:dmsmith555@yahoo.com"><dmsmith555@yahoo.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi,
I have fixed the bug in the search where bread returned 20 results
rather than over 350.
The problem was that it was using a PassageTally to collect the results.
I changed the code to call book.createEmptyKeyList(). This uses the
user's choice of Passage. By default it is set to RocketPassage. Is
there a better default?
I also changed the indexing to save the verse reference as UnIndexed. As
it was the verse was being indexed and stored. I didn't see a need to
index the verse as it is indexed already. And the search logic never
searched against that Field.
I also changed BookData to skip the children of the <div> element that
are not <verse> elements. The call to getPlainText still gets and
indexes the non-verse text in the <verse> element.
Gen 18.5 in the KJV is an example.
In His Service,
DM
_______________________________________________
jsword-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:jsword-devel@crosswire.org">jsword-devel@crosswire.org</a>
<a class="moz-txt-link-freetext" href="http://www.crosswire.org/mailman/listinfo/jsword-devel">http://www.crosswire.org/mailman/listinfo/jsword-devel</a>
</pre>
</blockquote>
<pre wrap=""><!---->_______________________________________________
jsword-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:jsword-devel@crosswire.org">jsword-devel@crosswire.org</a>
<a class="moz-txt-link-freetext" href="http://www.crosswire.org/mailman/listinfo/jsword-devel">http://www.crosswire.org/mailman/listinfo/jsword-devel</a>
</pre>
</blockquote>
</body>
</html>