fc.integer() causes non-terminating behaviour when given certain non-integer arguments for min and max

🐛 Bug Report

When using fc.integer() with max and min parameters, if 0.5 <= (max - min) < 1, then running through fc.assert(fc.property(...)) does not terminate.

To Reproduce

Steps to reproduce:

Any of the following lines do not terminate:

      fc.assert(fc.property(fc.integer({ min: 0, max: 0.5 }), () => true))
      fc.assert(fc.property(fc.integer({ min: 0, max: 0.999 }), () => true))
      fc.assert(fc.property(fc.integer({ min: 0.5, max: 1.4999 }), () => true))
      fc.assert(fc.property(fc.integer({ min: 0.5, max: 1 }), () => true))

All of the following do terminate:

      fc.assert(fc.property(fc.integer({ min: 0, max: 0 }), () => true))
      fc.assert(fc.property(fc.integer({ min: 1, max: 1 }), () => true))
      fc.assert(fc.property(fc.integer({ min: 0, max: 0.4999 }), () => true))
      fc.assert(fc.property(fc.integer({ min: 0, max: 1 }), () => true))
      fc.assert(fc.property(fc.integer({ min: 0, max: 1.5 }), () => true))
      fc.assert(fc.property(fc.integer({ min: 0.5, max: 1.5 }), () => true))

Expected behavior

I expect either:

• the min and max values behave as if they were rounded (or floored, or even ceiled) to an appropriate integer value,
• or an error to be thrown for specifying non-integer parameters.

Your environment

Packages / Softwares	Version(s)
fast-check	2.17.0
node	14.16.0
TypeScript	4.2.4

[dubzzz]

Does TS accept BigInt as number?

Actually no.

I think passing a value that type-checks fine but is somehow invalid ought to be caught early somehow.

Good point! We can clearly go for 2. I was mostly challenging a bit the need but your example makes it clear: it’s easy to fall in such case, so let’s add checks to ensure passed min/max are ok*. *meaning: between min safe and max safe, Number.isInteger

[dubzzz]

@julianmrodri Not related to this issue. Your issue is linked to the warning:

But be aware that using filter may highly impact the time required to generate a valid entry.

Visible here: https://github.com/dubzzz/fast-check/blob/main/documentation/AdvancedArbitraries.md#filter-values

In your case you ask the arbitrary for values between 0n and 115792089237316195423570985008687907853269984665640564039457584007913129639936n but only keep a very very very limited range. In your case filter will always reject the generated values as the chance to fall in your filtering range is barely null (bigUint arbitrary can produce any value with the same proba - more or less true once we stop biasing generated values).