[jsword-devel] regex searching

trent.jsword at trentonadams.ca trent.jsword at trentonadams.ca
Thu Feb 25 22:35:44 MST 2010 

1. This iteration method takes 1500-2000ms longer than the method I originally had. 
2. Mine takes 1500-2000ms longer when I use getCanonicalText() as well, making them virtually equal in search time
3. The pattern compiling, to my surprise, makes no difference on speed on the "simple" regular expression I was using. I guess it's just not enough matching to make a difference. I'm sure it would on millions of lines though. 
4. If I run mine with getCanonicalText() before I run yours, in the same run, yours takes half the time. I assume this is due to your caching thing. 


----- "DM Smith" <dmsmith at crosswire.org> wrote: 
> From: "DM Smith" <dmsmith at crosswire.org> 
> To: "Trenton D. Adams" <trent.jsword at trentonadams.ca>, "J-Sword Developers Mailing List" <jsword-devel at crosswire.org> 
> Sent: Thursday, February 25, 2010 8:54:31 PM GMT -06:00 US/Canada Central 
> Subject: Re: [jsword-devel] regex searching 
> 
> 
> 

On Feb 25, 2010, at 8:51 PM, trent.jsword at trentonadams.ca wrote: 




> This is not the fastest way I'm sure, but it did take 13 seconds. I don't know much about jsword yet, but I'm going to see if I can load entire books at a time, and go through them verse by verse. Bulk loading would likely be much faster. 
> 

> The problem with bulk loading is the assumption that SWORD has stored the verse in order. This is generally true, but not guaranteed. 

> 
We thought about giving the "engine" a passage to get and have it return the whole passage, but we haven't done that. JSword does have an optimization that when a block of compressed data is read, it is cached in core. If the next reference is for the same block, it is read from cache. This is the nature of compressed modules. 

> 
The shortcoming with the following is the setup to get the verse. It would be better to iterate over a bitmap holding a reference to the whole Bible. 

> 
See BookExporter for an example of iterating over the entire KJV efficiently: 
http://www.crosswire.org/jsword/java2html/org/crosswire/jsword/bridge/BookExporter.java.html 

> 
The other problem with your example is that each call to matches recompile the pattern. Hoist the pattern outside of the loop and it should be even faster. 

> 
A minor nit. OSISUtil.getPlainText(data.getOsisFragment()) will get titles and other non-canonical text. You probably want OSISUtil.getCanonicalText(data.getOsisFragment()); (Note, this will get canonical Psalm titles.) 

> 
Putting it together it would be something like: 

> 
Book book = Books.installed().getBook("KJV"); 

> Key keys = book .getGlobalKeyList(); 
> 
> 
> Iterator iter = keys.iterator(); 
> StringBuffer buf = new StringBuffer(); 
> 
> Pattern searchPattern = Pattern.compile( "wash.*word" ); 
> while (iter.hasNext()) { 
> Key key = (Key) iter.next(); 
> 
> BookData data = new BookData(book, key); 

> 
> String plainText = OSISUtil.getCanonicalText(data.getOsisFragment()) ; 
> if (plainText != null && plainText.trim().length() > 0) { 
> 
> Matcher m = searchPattern .matcher(plainText); 
> if (m.find()) { 
> buf.delete(0, buf.length()); 
> buf.append(key).append( ':' ).append(plainText); //$NON-NLS-1$ 
> System. out .println(buf.toString()); 
> } 
> } 
> } 

> 
Note this should work for all modules. Not just Bibles. 

> 
In Him, 
DM 

> 



> 
> Book book = Books.installed().getBook("KJV"); 
> if (book == null) 
> { 
> System.exit(1); 
> } 
> 
> long before; 
> long after; 
> 
> before = System.currentTimeMillis(); 
> for (int bookIndex = 1; bookIndex <= 66; bookIndex++) 
> { // all books 
> int maxChapters = BibleInfo.chaptersInBook(bookIndex); 
> for (int chapter = 1; chapter < maxChapters; chapter++) 
> { 
> int maxVerses = BibleInfo.versesInChapter(bookIndex, chapter); 
> for (int verse = 1; verse < maxVerses; verse++) 
> { 
> String bookName = BibleInfo.getBookName( 
> bookIndex).getLongName(); 
> Passage versePassage = (Passage) book.getKey(bookName + " " + chapter + ":" + verse); 
> BookData data = new BookData(book, versePassage); 
> String plainText = OSISUtil.getPlainText(data.getOsisFragment()); 
> if (plainText.matches(".*wash.*word.*")) 
> { 
> System.out.println(plainText); 
> } 
> 
> } 
> } 
> // System.out.println(BibleInfo.getBookName(bookIndex).getLongName()); 
> } 
> after = System.currentTimeMillis(); 
> 
> 
> John 13:12So after he had washed their feet, and had taken his garments, and was set down again, he said unto them, Know ye what I have done to you?tag 17 - has no greek word tag 12 "and was set down" 
> Ephesians 5:26That he might sanctify and cleanse it with the washing of water by the word, 
> Revelation of John 7:14And I said unto him, Sir, thou knowest. And he said to me, These are they which came out of great tribulation, and have washed their robes, and made them white in the blood of the Lamb.NOTE! Extra word: "stolei" 
> search took: 13280ms 
> 
> ----- "trent jsword" < trent.jsword at trentonadams.ca > wrote: 
> > From: "trent jsword" < trent.jsword at trentonadams.ca > 
> > To: "J-Sword Developers Mailing List" < jsword-devel at crosswire.org > 
> > Sent: Thursday, February 25, 2010 6:10:41 PM GMT -06:00 US/Canada Central 
> > Subject: Re: [jsword-devel] regex searching 
> > 
> > 
> > Well, I don't know how fast loading verses is in jsword, but my app takes .18 seconds, or possibly a little more depending on what you search for, for searching the entire bible. The bible text is on one verse per line, so there's no need to load one verse at a time. An example of a slow search, which is rare, would be "the.*or", which takes 18.32 seconds because it loads almost the entire bible over the internet, being that LARGE portions of scripture are found, lol) 
> > 
> > Try "blood.*sacrifice" on http://www.trentonadams.ca/biblesearch for an example of a relatively fast search. 
> > 
> > I can't imagine it being a "huge" amount slower with jsword, unless the file types that the data is stored in are particularly slow loading verses. But, jsword seems snappy enough, so I doubt it would be a problem. 
> > 
> > But, if regex was implemented, you could allow the person to specify "within X verses of each other". i.e. "wash" would be in v3 and "word" would be in v4 But it would probably require strange verse concatenations for one attempt, no concatenations for another attempt, shifting one verse at a time through the whole bible, etc, unless you wrote a regular expression parser of your own, that could find certain parts in one verse, and other parts in another. But that gets really complicated. So, on first thought, finding regular expressions between verses would be VERY time consuming. But that's just off the top of my head, so who knows, you might be able to do something fast. ;) 
> > 
> > ----- "Sijo Cherian" < sijo.cherian at gmail.com > wrote: 
> > > From: "Sijo Cherian" < sijo.cherian at gmail.com > 
> > > To: "J-Sword Developers Mailing List" < jsword-devel at crosswire.org > 
> > > Sent: Thursday, February 25, 2010 5:46:17 PM GMT -06:00 US/Canada Central 
> > > Subject: Re: [jsword-devel] regex searching 
> > > 
> > > What about finding terms across verse boudaries? As far as I remember the index documents are on per verse basis. So there is no way lucene query can find nearby words in a paragraph (across verse boundaries). Regex can help if we string-together verses or use Passage, but like DM mentioned, it will be slow to run regex (regex can be compiled once, but it has to run on so many verse strings). 

> > > 
BTW Is anyone working on getting search result highlighting? What needs to done besides using lucene-highlighter during the search? 

> > > 
-Sijo 

> > > 
> > > On Wed, Feb 24, 2010 at 11:05 PM, DM Smith < dmsmith at crosswire.org > wrote: 
> > > 

JSword search indexes support the full search syntax of Lucene. This has some support for regular expressions. Specifically, it allows for * to mean zero or more characters. I think we've got the Lucene flag to allow prefix wild cards. Note that this is more like what a shell uses: it is not a modifier for the previous character. 
> > > 
> > > It was correctly noted that wash.*word will not search the verse as a whole. Lucene search is based on words. The correct pattern in Lucene would be wash*word, as '.' does not mean any character but rather it means a punctuation mark. So "wash.*word" would be split into "wash *word" and would find all verses with the word "wash" and any word ending with "word", such as "sword". 
> > > 
> > > The default connector for JSword is OR. It would be good to add the ability for a user to change it to AND. With that, "wash* word" would produce the expected results as it would be interpreted as "wash* AND word" instead of "wash* OR word". (Choice would be some thing like "Search for ALL words instead of ANY words.") We made OR the default because it more closely matched various familiar search engines, such as Google, and because it is the default of Lucene. 
> > > 
> > > Lucene does have a regular expression capability, but it is not part of JSword. It would be a good addition. Still, it would be based on words and not on the text of a verse. 
> > > 
> > > Adding the ability to search an arbitrary regular expression would be a good addition. I don't think it would be too hard to add it. Jsword already has the interface for any search implementation. Java's Regex is a variant of Perl's but has a bit more power. There are some issues: We'll be adding highlighting to Lucene's search. Adding that to Regex would be a separate effort. The regex search would be mutually exclusive from Lucene search, so that would need to be made obvious. (In The SWORD Project for Windows, they have both it is a bit confusing as it is not clear.) 
> > > 
> > > And yes, it will need to go throw the "plain" text of each verse. It will be about as slow as creating an index. Basically, it will need to take the raw verse and strip the markup. (This is part of JSword already and Lucene indexing uses it.) And perhaps strip out the punctuation. Finally doing the search. 
> > > 
> > > If you want, add an issue or two to Jira ( www.crosswire.org/bugs ) under JSword. That way it won't be forgotten. 
> > > 
> > > In Christ, 
> > > DM 


> > > 
> > > 
> > > 
> > > On 02/23/2010 08:33 PM, Trenton D. Adams wrote: 
> > > 

But then again, I wonder if it's even needed, who knows. 
> > > 
> > > ----- "Trenton D. Adams"< trent.jsword at trentonadams.ca > wrote: 
> > > 
> > > 
> > > 

From: "Trenton D. Adams"< trent.jsword at trentonadams.ca > 
> > > To: "J-Sword Developers Mailing"< jsword-devel at crosswire.org > 
> > > Sent: Tuesday, February 23, 2010 7:29:08 PM GMT -06:00 US/Canada Central 
> > > Subject: [jsword-devel] regex searching 
> > > 
> > > Hello, 
> > > 
> > > I'm getting the impression that regular expression searching is not at 
> > > all possible without implementing something that loads the books 
> > > itself, and goes through each verse of the bible. Is this true? 
> > > 
> > > It seems like the Lucene Index just doesn't support regular expression 
> > > searches, eh? And it also seems like SearcherFactory is currently not 
> > > finished being implemented as a SearcherFactory, correct? Or, perhaps 
> > > other methods need to be added, like createSearcher(Book, Class 
> > > searcherClass)??? Then you could provide another searcher type. 
> > > 
> > > What would be appropriate for this? adding the new 
> > > SearcherFactory.createSearcher(), adding another "find" method to 
> > > AbstractBook/Book that is something like "find(SearchRequest, 
> > > Searcher)"??? 
> > > 
> > > Are the books and everything abstract enough that I can search them by 
> > > loading the text? Or would I have to restrict it to the book types I 
> > > know how to parse? 
> > > 
> > > Anything else? 
> > > 
> > > Thanks. 
> > > 
> > > _______________________________________________ 
> > > jsword-devel mailing list 
> > > jsword-devel at crosswire.org 
> > > http://www.crosswire.org/mailman/listinfo/jsword-devel 
> > > 
> > > _______________________________________________ 
> > > jsword-devel mailing list 
> > > jsword-devel at crosswire.org 
> > > http://www.crosswire.org/mailman/listinfo/jsword-devel 
> > > 
> > > 
> > > 
> > > _______________________________________________ 
> > > jsword-devel mailing list 
> > > jsword-devel at crosswire.org 
> > > http://www.crosswire.org/mailman/listinfo/jsword-devel 
> > > 
> > > 

> > > -- 
> > > Regards, 
> > > Sijo 
> > > 
> > > _______________________________________________ jsword-devel mailing list jsword-devel at crosswire.org http://www.crosswire.org/mailman/listinfo/jsword-devel 
> > _______________________________________________ jsword-devel mailing list jsword-devel at crosswire.org http://www.crosswire.org/mailman/listinfo/jsword-devel _______________________________________________ 
> jsword-devel mailing list 
> jsword-devel at crosswire.org 
> http://www.crosswire.org/mailman/listinfo/jsword-devel 
> 
>

More information about the jsword-devel mailing list