Patch w/ simple test showing the bug ... I'm not sure how to fix yet.

I'm not sure either if the problem is in ValueSource which implements longVal() to return (long) doubleVal(doc), or that we need to check the actual range type in RangeAccumulator and somehow pull the right value and pass it to the right method (e.g. maybe adding Range.accept variant for int/float/double)... we could have these variants throw UOE (or return false) at the base Range class and have each Range override that one that it cares about. But then it means we need to duplicate the code which traverses the ranges to work with the right value...

I'll think about it more.

At any rate, I think the test should move to demo/ so that we don't introduce the dependency on expressions in the facet module.

Or, we could modify the test to use a custom ValueSource which mimics expression's behavior (not encoding the double as long, but just casting).

You dont even need a custom valuesource: they all behave this way (e.g. same as java.lang.Number): the bug is as mike describes.

RangeFacetRequest always uses LongFieldSource, regardless of the type of Range the user passes in.

I don't think that's the case (but I'm not near the code to double-check). LongFieldSource is only used in the ctor which takes a field name, and as documented - reads the values from the respective NDV field. Mike's test uses Expression and its ValueSource.

I think a solution could be to separate RangeAccumulator into a NumericRangeAccumulator and ValueSourceRangeAccumulator. The former always reads from an NDV and takes whatever range. The latter could restrict to only taking DoubleRange, and always call vs.doubleVal, since that seems like the only API a ValueSource has to impl. Or, it takes any Range, but always calls vs.doubleVal and converts it to Long, and the Range can convert it back?

Commit 1546809 from Michael McCandless in branch 'dev/branches/lucene5339'
[ https://svn.apache.org/r1546809 ]

LUCENE-5345: split RangeFacetCounts into Long/DoubleRangeFacetCounts

On the LUCENE-5339 branch, I just made a change to split RangeFacetCounts into Long/DoubleRangeFacetCounts, and I removed FloatRange (leaving only Long/Double). When the app needs to count ranges against a previously indexed FloatDocValuesField, it can use FloatFieldSource. It seems to work well... the new test passes.

Is it mandatory to have facet/ depend on expressions? Can't we do it under demo/ only, and use mock ValueSources for testing facet/?

Commit 1546812 from Michael McCandless in branch 'dev/branches/lucene5339'
[ https://svn.apache.org/r1546812 ]

LUCENE-5345: move the distance example to demo

Is it mandatory to have facet/ depend on expressions? Can't we do it under demo/ only, and use mock ValueSources for testing facet/?

You're right, I just moved it to demo/ and left a "custom doubles values source" test in facet/

This was fixed with LUCENE-5339.

Commit 1556952 from Michael McCandless in branch 'dev/trunk'
[ https://svn.apache.org/r1556952 ]

LUCENE-5345: add new BlendedInfixSuggester

Commit 1556954 from Michael McCandless in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1556954 ]

LUCENE-5345: add new BlendedInfixSuggester

Woops, above commit was for LUCENE-5354 instead.

You can try fixing the log message, I wonder if it will associate it then with the right JIRA issue. I think I've done it once while working on NDV updates. See the accepted answer here: http://stackoverflow.com/questions/304383/how-do-i-edit-a-log-message-that-i-already-committed-in-subversion (with a snippet from the SVN documentation).

OK I just fixed it! Thanks for the tip Shai.