Give fractions and decimals min_value and max_value flags

[DRMacIver]

These mirror the other numeric types (integers, floats).

Note that this is a harder problem than it sounds because the way they're currently implemented does not make it straightforward at all.

It should be pretty feasible to do an exact implementation for fractions but will probably require a custom strategy implementation (it could be done with flatmap, but I would rather it weren't).

Decimals should just be able to convert its bounds to floats and fractions respectively, pass those through to the underlying stragies, and then filter the end result to deal with any imprecision.

[waynew]

I suspect this would really shave a lot of time off of my tests: right now I'm using assume(decimal.is_finite() and 0 < int(decimal) < 50000), and I'm pretty sure that requires a lot more generations than it could have.

[DRMacIver]

Yeah, if you're doing that you're probably discarding a lot of examples before you find good ones.

Note that this is a help-wanted ticket. If you wanted to submit a pull request I'd be very happy to help you write it (see https://hypothesis.readthedocs.org/en/latest/development.html for details of how this works).

[moreati]

I'm having a go at this

[moreati]

I'm afraid I didn't make progress on this, and I've run out of time.

[mulkieran]

I think that there are some subtleties about fractions and how you would want to test w/ them that I have inadvertently explored in https://github.com/mulkieran/justbases. I don't use the fractions strategy much at all in my tests, instead synthesizing fractional values from integers in various ways. Maybe, since this is up for grabs anyway, it might make sense to think of a few other parameters for fractions strategy that might also be important to have. I will try.

[mulkieran]

Stalls on testRoundFraction()...one of the two places where I was casual enough to use the fractions() strategy: https://travis-ci.org/mulkieran/justbases/builds/110134095.

[mulkieran]

Possibly boundng overall size and also size of numerator and denominator would be enough.

[mulkieran]

It turned out for most of my tests that used fractions() strategy it was necessary to call the Fraction.limit_denominator() method to get the tests to pass in a reasonable time. This was due to the fact that these tests used an explicit, precise division, with an algorithmic efficiency bounded only by the size of the denominator. So, if I limit the denominator to 100, then I have to do at most 100 divisions before I have calculated the repeating portion of the result. This is at least a hint of what modifiers the strategy should have.

[mulkieran]

Maybe max_value, min_value, an upper bound on the absolute value of the product of the numerator and the denominator OR an upper bound on the absolute value of both numerator and denonimator would be adequate.

[Zac-HD]

Closed by #327