On Wed, Apr 20, 2011 at 3:01 PM, Daniel Fischer
I'm sure it's not criterion, because after I've found that NaNs were introduced to the resamples vectors during sorting (check the entire vectors for NaNs before and aftersorting, tracing the count; before: 0, afterwards often quite a number, sometimes close to 10%), the further tests didn't involve criterion anymore. criterion is simply the most obvious place to see the NaNs show up (with 5-10% NaNs among the resamples, it won't take too long to see one pop up).
It could be a bug in statistics, but I'm pretty sure this one's not due to statistics either, since fiddling with vector-algorithms made the NaNs disappear - btw., Bryan, using the heap sort instead of introsort, I haven't found any NaNs in my tests, so temporarily switching the algorithm might cure the symptoms.
It's not a statistics bug. I'm reproducing it here using just vector-algorithms. Fill a vector of size N with [N..1], and (intro) sort it, and you get NaNs. But only with -O or above. Without optimization it doesn't happen (and nothing seems to be reading/writing out of bounds, as I compiled vector with UnsafeChecks earlier and it didn't complain). Filling the vector with [1..N] also doesn't trigger the NaNs. [0,0..0] and [0,0..1] trigger it. I don't know what's going on yet. I have trouble believing it's a bug in vector-algorithms code, though, as I don't think I've written any RULEs (just INLINEs), and that's the one thing that comes to mind in library code that could cause a difference between -O0 and -O. So I'd tentatively suggest it's a vector, base or compiler bug. The above testing is on 64-bit windows running a 32-bit copy of GHC, for reference. My ability to investigate this will be a bit limited for the near future. If someone definitively tracks it down to bugs in my code, though, let me know, and I'll try and push a new release up on hackage. -- Dan