Unable to compute stats for some features

[pramsey]

It looks like some input data might include extremely small M values as a default value

 POINT ZM (-124.22007 41.75967 0 -1.79769313486232e+308)

A table of these things will result in the following when ANALYZE is run

NOTICE: no non-null/empty features, unable to compute statistics

The problem is that the large M value is so large that when it's converted to a float for storage in gserialized, it actually goes to Inf, so that when the box is retrieved from the serialization, the result is this:

(GBOX) $7 = (flags = '\x03', 
 xmin = -124.22007751464844, xmax = -124.22006988525391, 
 ymin = 41.759666442871094, ymax = 41.759670257568359, 
 zmin = 0, zmax = 0, 
 mmin = -Inf, mmax = -Inf)

[pramsey]

fix based on pushing huge doubles values to FLT_MAX/FLT_MIN

[pramsey]

So, my fix just catches cases where a big double gets converted into an Inf float, and instead converts them into MAX_FLT/MIN_FLT (depending on whether it's positive or negative). I feel like that's "OK", in a practical sense, since we're talking about values > 10^{38 here.}

Another solution would be to try and fit the estimation code to still fail in cases of Inf boxes, but instead to fail a bit more selectively, since in the case of this example it would be possible to compute a 2D stats histogram, just not a 4D one. Unfortunately a lot of the code works in the ND case and the 2D case is just a small specialization.

[pramsey]

I put in a different, more "correct" solution at r13030 on trunk, r13031 on 2.1.

Rather than force the box into a "valid" space in all cases, I just trip the higher dimensions when in the 2d mode. This results in good stats for 2d, and bad stats of n-d, which fixes 95% of the use cases. If you're building an nd-index on this crazy Z/M data, then you can deal with the badness.

[strk]

Reviewed. Sounds good. Maybe the comment could be more specific about what "safety" it's after. It looks to me it is just a way to only consider 2D when checking for validity (ie: a replacement for a missing gbox_is_valid2d). Is that correct ?