|From:||Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>|
|To:||Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>|
|Cc:||Yura Sokolov <y(dot)sokolov(at)postgrespro(dot)ru>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Aleksander Alekseev <aleksander(at)timescale(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>|
|Subject:||Re: rand48 replacement|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
>>> 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.
|Next Message||Fabien COELHO||2021-07-08 12:31:16||Re: rand48 replacement|
|Previous Message||Thomas Munro||2021-07-08 12:17:28||Re: pgbench logging broken by time logic changes|