I don't think this qualifies for an exception to the freezing of RandomState per NEP 19. I think this should be confined to Generator.

Please update the Notes section which still refers to the old behavior.

I agree with @rkern that we cannot change mtrand.pyx in this instance, and so the PR is limited to the new generator. It adds a check. An alternative would be to better explain that role of high low and make this the default behaviour. Something along the lines of

The input values are not checked for order. The uniform is generated as low + (high - low) * random(), so that if
high < low, then the uniform is generated as if high and low are swaped.

Probably simpler to enforce though. Probably will also help to avoid hard to detect bugs by end-users.

2. Just curious what happens/should happen for low == high, and if we should test that.

That case is documented, if not tested. It always returns the constant low (or equivalently, high).

What about integers? There is #14333, which has other problems, but it seems somewhat related.

What about integers? There is #14333, which has other problems, but it seems somewhat related.

#14333 is mostly a preference about the error message. This is about whether this is high > low is actually an error.

Thanks @bashtage

With this change, it's now harder to generate a random number in the half-open interval (low, high], which I get the feeling was what passing the arguments in the "wrong" order did. Are we sure it wasn't better to support that use-case?

With this change, it's now harder to generate a random number in the half-open interval (low, high], which I get the feeling was what passing the arguments in the "wrong" order did. Are we sure it wasn't better to support that use-case?

That feels like a magic incarnation, at least given the lack of clear intent for this case doc. It doesn't seem to be that much larger to do what you wish.

-gen.uniform(-high, -low)

With floating point arithmetic, there are very no real guarantees that you'll actually get a half-open interval, on either side.

there are very no real guarantees that you'll actually get a half-open interval, on either side.

Ah, I was misled by the docstring which seems to suggest the interval is truly half-open, only to remark in the notes that this is not guaranteed. Sounds like my concern isn't relevant, thanks for clarifying.

There's definitely room for a uniform-like method that fully controls whether the ends are open or closed, in any combination. But it should also enforce low <= high and control the open/closed-ness through other arguments.