allow_subnormal keyword for complex_numbers

[renefritze]

I would like to be able to exclude subnormals from the floats drawn (or more specifically the resulting imaginary and real parts of the constructed complex number) in the complex_numbers strategy, but that's currently not possible.
Has this been considered already?

[honno]

Worth noting supporting v2 of the Array API in hypothesis.extra.array_api, which includes complex numbers which would presumably make subnormals out-of-scope, would probably want this feature. (I'll have to write a separate issue outlining the different approaches we could take for v2 support generally).

[Zac-HD]

I think we're only missing this because nobody has asked for it before! Very happy to accept a PR from you or @honno; otherwise expect a patch from the scipy sprints.

Just to confirm, I think the sensible way to interpret allow_subnormal=False for complex numbers is that it applies to the real and the imaginary parts, yes? Should make it easy to document and also implement, we just pass it through to the floats strategies internally.

[renefritze]

Just to confirm, I think the sensible way to interpret allow_subnormal=False for complex numbers is that it applies to the real and the imaginary parts, yes?

I think it's important that the resulting complex number drawn from this strategy has no subnormal real or imaginary part, yes.

Should make it easy to document and also implement, we just pass it through to the floats strategies internally.

I think one would need to look at the min/max magnitude constrained code path and check if this is really all that's necessary?
The unconstrained case is definitely trivial.

[honno]

(self assigning although anyone else feel free to go for it, I'll probably start on this in a few weeks time)

[honno]

Oh I see, if this is a good sprint task for the US SciPy con coming up then I'm happy to step-back and review! Otherwise yeah will get to it later.

[Zac-HD]

Yeah, if this hasn't been done before the sprints someone will pick it up there.

I think one would need to look at the min/max magnitude constrained code path and check if this is really all that's necessary?

We already have a non-obvious design to make this work for the allow_infinity and allow_nan arguments (motivated by nice shrinking), so that really is all it takes!