Define end-of-paragraph

Hello, I have just started to work with Lucene I want to divide a document to paragraphs, still having proximity search within each paragraph How can I do that? Thanks in Advance Reuven Ivgi

Re: Define end-of-paragraph

Reuven Ivgi wrote on 10/02/2006 09:32 PM: > I want to divide a document to paragraphs, still having proximity search > within each paragraph > > How can I do that? > Is your issue that you want the paragraphs to be in a single document, but you want to limit proximity search to find matches on

RE: Define end-of-paragraph

Hello, To be more precise, the basic entity I am using is a document, each with paragraphs which may be up to few thousands. I need the proximity search within a paragraph, yet, I want to get as a search result the paragraph number also. Maybe, defining each paragraph as separate field it the best

Re: Searching with "1"

After thinking through what was happening in Hits, I decided to see if catching a general exception would come back with anything. Although it can be argued that the code should have been doing this all along, that is a different story. So, I added Exception to the catch clauses, and it in fact

Re: Searching with "1"

djd0383 wrote: After thinking through what was happening in Hits, I decided to see if catching a general exception would come back with anything. Although it can be argued that the code should have been doing this all along, that is a different story. So, I added Exception to the catch clauses,

[jira] Commented: (LUCENE-677) Italian Analyzer

[ http://issues.apache.org/jira/browse/LUCENE-677?page=comments#action_12439640 ] Federico Grilli commented on LUCENE-677: I guess you already got my answer through the lucene-dev mailing list. In any case, the answer is yes, same stemmi

Re: Define end-of-paragraph

Hi Reuven, In my haste last night, I pointed you at the wrong fields on Token. You need to set the position to create inter-paragraph gaps, not the offsets, so you want Token.setPositionIncrement() for that approach, or Analyzer.getPositionIncrementGap() if you use the multi-field approach. You w

[jira] Commented: (LUCENE-664) [PATCH] small fixes to the new scoring.html doc

[ http://issues.apache.org/jira/browse/LUCENE-664?page=comments#action_12439675 ] Doug Cutting commented on LUCENE-664: - > So this means replacing *indexBoost* with *norm* ? Yes, that was my suggestion. > I think that norm depends on the fi

[jira] Updated: (LUCENE-489) Allow QP subclasses to support Wildcard Queries with leading "*"

[ http://issues.apache.org/jira/browse/LUCENE-489?page=all ] Steven Parkes updated LUCENE-489: - Attachment: LUCENE-489.patch I was looking in this area (wildcard prefixes) so I figured I might as well do the cleanup. Dan's patch, with newly generated j

Is it save to remove the throw from FastCharStream.refill() ?

Hi folks, Over at Lucene.Net, we are trying to determine if it's safe to do the following change: http://issues.apache.org/jira/browse/LUCENENET-8 Can you tell us, if this change is done on the Java Lucene code, how it will effect Lucene? Do you expect the it to run faster but more importantly,

Re: Is it save to remove the throw from FastCharStream.refill() ?

The throwing of an exception by this class is still being done on the Java side at this stage IIRC, and is also extremely bad for performance in Java. However I think the client of the class (one of the Filters I think) is expecting the EOF exception as a signal that it has received the en

Re: Is it save to remove the throw from FastCharStream.refill() ?

Yeah, I don't think it's easy to get rid of the exception because the client of FastStreamChar is JavaCC generated code, which AFAIK uses the exception in lieu of explicit EOF checking. -Yonik http://incubator.apache.org/solr Solr, the open-source Lucene search server On 10/3/06, Paul Smith <[E

Re: Is it save to remove the throw from FastCharStream.refill() ?

A related prior discussion is at http://issues.apache.org/bugzilla/ show_bug.cgi?id=34930 Wolfgang. On Oct 3, 2006, at 7:08 PM, Yonik Seeley wrote: Yeah, I don't think it's easy to get rid of the exception because the client of FastStreamChar is JavaCC generated code, which AFAIK uses the exc