Fix random.binomial(...) to accept dtype=int

[aghilann]

Summary:
The binomial function previously only accepted floating-point dtypes, even though it should typically return integers. This PR allows integer dtypes (e.g., int32, int64) while preserving backward compatibility by keeping floats as the default.
I verified the changes by:

• Adding unit tests to check that the return type matches the specified dtype.
• Ensuring existing tests that validate output values continue to pass.

Fixes #28457

[jakevdp]

Thanks for taking a look at this! A few comments below

[aghilann]

Thanks for taking a look at this! A few comments below

Resolved comments, thanks for the detailed review. This is my first open-source contribution, so apologies for any newbie mistakes!

[jakevdp]

Let's use float_type = dtypes.to_inexact_dtype(dtype) to respect the input dtype if it's floating point.

[jakevdp]

What happens here when the sampler returns NaN or inf and dtype is integer? Is it the correct semantics for those cases? (this is a hard question to answer, and probably why float dtypes were required in the original implementation).

[aghilann]

I'm honestly not entirely sure what the best course of action would be. Could we disallow a dtype of int if a NaN or inf is present?

[jakevdp]

No, that's not possible unfortunately. dtypes are specified statically (i.e. at compile time) and the value of p in general is not known until runtime. Static quantities cannot be dependent on dynamic quantities.

[aghilann]

What do you think about adding logic like this to sanitize the values before the round and cast?

if dtypes.issubdtype(dtype, np.integer):
    # replace NaN→0, +∞→max, -∞→min before rounding
    info = np.iinfo(dtype)
    samples = jnp.nan_to_num(
        samples,
        nan=0.0,
        posinf=info.max,
        neginf=info.min,
    )
    samples = jnp.round(samples)

[jakevdp]

Something like that may work, but I wonder if it wouldn't be less confusing to just keep requiring float output? Why do we need to support integer output if it will lead to ambiguities?

For reference, I found the place where output type was originally discussed: #16134 (review)

[aghilann]

Reading that discussion, I understand now why a float dtype was chosen - it wasn’t just a bug. I think my solution could work, but I’m not sure it justifies the added complexity and potential confusion. The only reason I added support for int outputs is because someone raised the issue, and I initially thought it was a bug. Should we go ahead and close this PR?

By the way, I casually browsed the issues for any good first ones, but if you ever come across something small that you’d like help with, feel free to tag me - I'm happy to contribute.