: In general I would agree that people may want different implementations for
: compare(), but I hardly see that's the case for ScoreDoc. After all, you can
: either compare it by score or by doc (at least now). I believe that since
: most people use the TopDocsHitCollector, they prefer the compar
In general I would agree that people may want different implementations for
compare(), but I hardly see that's the case for ScoreDoc. After all, you can
either compare it by score or by doc (at least now). I believe that since
most people use the TopDocsHitCollector, they prefer the compare-by-scor
Did it crash on the 10 GB? I thought it said that it just took way to
long (7 times the best or something). Frankly, either case is suspect.
Last summer I indexed about 5 million docs with a total size at the
*very* least of 10 GB on my 3 year old desktop. It didn't take much more
than 8 hours
All true and good points. Lucene held up quite nicely in the search
aspect (at least perf. wise) and I generally don't think making these
kinds of comparisons are all that useful (we call it apple and oranges
in English :-) ).
What I am trying to get at is if this paper was just about Luc
Any unclosed and unused searcher that doesn't get closed will simply get
garbage collected when its time is up and when the GC gets to it.
Are you seeing problems with the spellchecker?
Otis
--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
- Original Message
From: sujit
There is an expression in French that says "comparer des pommes et des
poires" which literally means "to compare apples and pears". That's what
this paper is about. For my point of view, such a comparison would be
interesting only if a cross analysis of different criterions (for example,
retrieval
increase default maxFieldLength?
Key: LUCENE-1084
URL: https://issues.apache.org/jira/browse/LUCENE-1084
Project: Lucene - Java
Issue Type: Improvement
Components: Index
Affects Versions: 2.2
Yes, and even if they did not use the stock defaults, I would bet there
would be complaints about what was done wrong at every turn. This seems
like a very difficult thing to do. How long does it take to fully learn
how to correctly utilize each search engine for the task at hand? I am
sure lon
There is a good chance that they were using stock indexing defaults,
based on:
Lucene:
" In the present work, the simple applications
bundled with the library were used to index the collection. "
On 7-Dec-07, at 10:27 AM, Grant Ingersoll wrote:
Yeah, I wasn't too excited over it and I certain
[
https://issues.apache.org/jira/browse/LUCENE-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549526
]
Matt Doar commented on LUCENE-1083:
---
As an aside, Maven repositories in general could usefully be enhanced to
reco
Yeah, I wasn't too excited over it and I certainly didn't lose any
sleep over it, but there are some interesting things of note in there
concerning Lucene, including the claim that it fell over on indexing
WT10g docs (page 40) and I am always looking for ways to improve
things. Overall, I
[
https://issues.apache.org/jira/browse/LUCENE-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549500
]
Doug Cutting commented on LUCENE-1083:
--
The "prior release" is a new concept that needs to be added to the buil
[
https://issues.apache.org/jira/browse/LUCENE-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549475
]
Matt Doar commented on LUCENE-1083:
---
Grant,
I was imagining more that the release process for Lucene could be cha
I wouldn't get too excited over this. Once again, it does not seem
the evaluator understands the nature of GC based systems, and the
memory statistics are quite out of whack. But it is hard to tell
because there is no data on how memory consumption was actually
measured.
A far better way
[
https://issues.apache.org/jira/browse/LUCENE-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549429
]
Grant Ingersoll commented on LUCENE-1083:
-
Thanks, Matt. I assume the antjdiff.jar needs to be included som
Was wondering if people have seen
http://wrg.upf.edu/WRG/dctos/Middleton-Baeza.pdf
Has some interesting comparisons. Obviously, the comparison of Lucene
indexing is done w/ 1.9 so it probably needs to be done again. Just
wondering if people see any opportunities to improve Lucene from
it
[
https://issues.apache.org/jira/browse/LUCENE-1077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grant Ingersoll resolved LUCENE-1077.
-
Resolution: Fixed
Lucene Fields: (was: [New])
Committed
> New Analysis Contri
[
https://issues.apache.org/jira/browse/LUCENE-1082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless resolved LUCENE-1082.
Resolution: Fixed
Fix Version/s: 2.3
I just committed this. Thanks Alan!
18 matches
Mail list logo
