Redesign support for NumericRange facets (on matchspy branch)

[Richard Boulton]

Issues to be addressed before doing this:

• Is the standard scheme useful?
• Should we be returning the ends of the buckets (so adjacent buckets meet up), or the maximum and minimum values in the buckets. Or is returning both the most useful approach.
• What's the best API for implementing different bucketing schemes. The current API is to make a new subclass of NumericRanges to implement a new bucketing scheme, and all the work is done in the constructor: this seems poor. Really, we should have some kind of factory methods to create the ranges.
• We need support for logarithmic ranges, since they're very common.
• We need to document properly what the current scheme does.

[Olly Betts]

Hmm, I thought you'd concluded that the bucketing stuff didn't really do what users actually wanted?

Perhaps that's the first point, and our discussion of that happened after this ticket.

If so, let's either close this ticket, or morph it into a place to track implementing something which produces such buckets but in a way which is actually useful!

[Richard Boulton]

Without looking at the code again, my memory is that the automatic range guessing didn't work as users really wanted. However, it would still be useful to have something which allowed a set of ranges to be supplied (probably after getting the min and max values from the spy, after the search has run), and which then calculates the number of values in each range.

[Olly Betts]

1.3.x material now.

[Olly Betts]

This would most likely be an API addition, so not a 1.4.0 blocker.