Re: rand48 replacement
От | Fabien COELHO |
---|---|
Тема | Re: rand48 replacement |
Дата | |
Msg-id | alpine.DEB.2.22.394.2107081330010.12668@pseudo обсуждение исходный текст |
Ответ на | Re: rand48 replacement (Dean Rasheed <dean.a.rasheed@gmail.com>) |
Список | pgsql-hackers |
>>> 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.
Вложения
В списке pgsql-hackers по дате отправления: