Two things: First, the version of variant I gave will behave reasonably if given a negative argument, so the overflow is not catastrophic. Second, I'm not sure what you mean by a "simple" generator. Let's consider Int instead of Double. With the current version of variant, "coarbitrary 1" calls split one time, and "coarbitrary 1000" calls split 1000 times. At the end of the day, though, all random number generators are equally "complex". The only difference is that they have different seeds. You are correct the QuickCheck2 uses "toRational" instead of "decodeFlloat" for the coarbitrary instance. I don't think it matters either way which one gets used, though, and I would rather change as little code as possible in QuickCheck1. Patrick Jed Brown wrote:
I haven't looked at this in a while but I'm not sure this completely fixes things with regard to coarbitrary. That is, we can produce very simple Doubles (as defined by arbitrary) that produce (via coarbitrary) very complicated generators for other types (and there was an issue of overflow with possible sign change due to nasty casting, hence variant getting a negative argument). As I understand it, your fix to variant means that variant will return in a reasonable amount of time even with a huge argument, but it doesn't fix the issue that coarbitrary should produce a `simple' generator for a `simple' argument. I thought QC2 had a mechanism to fix this.