[jira] Commented: (LUCENE-517) norm compression breaks ranking for small fields

[ http://issues.apache.org/jira/browse/LUCENE-517?page=comments#action_12369936 ] Randy Puttick commented on LUCENE-517: -- Thanks Yorik, this could work for my purposes; it'd be nice to have a choice on a per-field basis don't you think? > norm compres

[jira] Commented: (LUCENE-517) norm compression breaks ranking for small fields

[ http://issues.apache.org/jira/browse/LUCENE-517?page=comments#action_12369928 ] Yonik Seeley commented on LUCENE-517: - Yes, the error bars seem kind of large for the normal usage of norms, which is just length normalization if you don't include boosts

[jira] Commented: (LUCENE-518) document field lengths count analyzer synonym overlays

[ http://issues.apache.org/jira/browse/LUCENE-518?page=comments#action_12369918 ] Randy Puttick commented on LUCENE-518: -- What you say would make sense if you thought that queries would contain several synonyms. All my experience says that they don't;

Re: Filter

On 3/10/06, eks dev <[EMAIL PROTECTED]> wrote: > It looks to me everybody agrees here, not? If yes, it > would be really usefull if somebody with commit rights > could add 1) and 2) to the trunk (these patches > practically allready exist). Perhaps after 2.0 is out... I don't think new features ar

[jira] Commented: (LUCENE-518) document field lengths count analyzer synonym overlays

[ http://issues.apache.org/jira/browse/LUCENE-518?page=comments#action_12369908 ] Yonik Seeley commented on LUCENE-518: - I'm not sure... I can think of examples either way. If a field has a lot of synonyms, it will match more terms. Shouldn't it's length

[jira] Created: (LUCENE-518) document field lengths count analyzer synonym overlays

document field lengths count analyzer synonym overlays -- Key: LUCENE-518 URL: http://issues.apache.org/jira/browse/LUCENE-518 Project: Lucene - Java Type: Bug Components: Index Versions: 1.9 Environmen

Re: Filter

Hi, All, For the filter issue, my idea is to completely get rid of the filter interface. Can we not use the HitCollector and have that to do the filtering work? I am in the process of writing a simpler engine based on Lucene source code. I don't mind re-inventing the wheel, as I feel frustrated w

[jira] Created: (LUCENE-517) norm compression breaks ranking for small fields

norm compression breaks ranking for small fields Key: LUCENE-517 URL: http://issues.apache.org/jira/browse/LUCENE-517 Project: Lucene - Java Type: Bug Components: Index, Search Versions: 1.9 Environment: N

[jira] Closed: (LUCENE-516) TestFSDirectory fails on Windows

[ http://issues.apache.org/jira/browse/LUCENE-516?page=all ] Yonik Seeley closed LUCENE-516: --- Fix Version: 2.0 Resolution: Fixed Assign To: Yonik Seeley The test fails for me too. I looked into it a while ago, and a way to fix it wasn't obv

Re: Filter

It looks to me everybody agrees here, not? If yes, it would be really usefull if somebody with commit rights could add 1) and 2) to the trunk (these patches practically allready exist). It is not invasive change and there are no problems with compatibility. Also, I have noticed a lot of people try