>>> Finally, I think it would be better to treat the upper bound of the
>>> range as inclusive.
>>
>> This bothered me as well, but the usual approach seems to use range as the
>> number of values, so I was hesitant to depart from that. I'm still
>> hesitant to go that way.
>
> Yeah, that bothered me too.
>
> For example, java.util.Random.nextInt(bound) returns a value in the
> range [0,bound).
>
> But other implementations are not all like that. For example python's
> random.randint(a,b) returns a value in the range [a,b].
>
> Python also has random.randrange(start,stop[,step]), which is designed
> for compatibility with their range(start,stop[,step]) function, which
> treats "stop" as exclusive.
>
> However, Postgres tends to go the other way, and treat the upper bound
> as inclusive, as in, for example, generate_series() and pgbench's
> random() function.
>
> I think it makes more sense to do it that way, because then such
> functions can work all the way up to and including the limit of the
> bound's datatype, which makes them more general.
Yep. Still, with one argument:
- C#: Random Next is exclusive
- Go: rand Intn is exclusive
- Rust: rand gen_range is exclusive
- Erlang: rand uniform is inclusive, BUT values start from 1
The rule seems to be: one parameter is usually the number of values, thus
is exclusive, 2 parameters describes the range, this is inclusive.
Attached a v10 which is some kind of compromise where the interface uses
inclusive min and max bounds, so that all values can be reached.
--
Fabien.
