|
|
|
#1 |
|
Messages: n/a
Hébergeur: |
On 9/15/07, kendear <summercoolness@gmail.com> wrote:
> given the ease of using Ruby, I wonder whether we will have rand(m, n) in > the future... > > right now, we need to use rand(range) + start > > and it can cause a bug that can otherwise be avoided if we have rand(m, n) > for the clarity. Why not instead suggest rand(m..n)? That would, I think, be more readable than rand(m, n). -austin -- Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/ * austin@halostatue.ca * http://www.halostatue.ca/feed/ * austin@zieglers.ca |
|
|
|
#2 |
|
Messages: n/a
Hébergeur: |
On 9/15/07, Austin Ziegler <halostatue@gmail.com> wrote:
> On 9/15/07, kendear <summercoolness@gmail.com> wrote: > > given the ease of using Ruby, I wonder whether we will have rand(m, n) in > > the future... > > > > right now, we need to use rand(range) + start > > > > and it can cause a bug that can otherwise be avoided if we have rand(m, n) > > for the clarity. > > Why not instead suggest rand(m..n)? That would, I think, be more > readable than rand(m, n). But would that draw discrete or continuous random numbers? Hadley |
|
|
|
#3 |
|
Messages: n/a
Hébergeur: |
On 15.09.2007 17:39, hadley wickham wrote:
> On 9/15/07, Austin Ziegler <halostatue@gmail.com> wrote: >> On 9/15/07, kendear <summercoolness@gmail.com> wrote: >>> given the ease of using Ruby, I wonder whether we will have rand(m, n) in >>> the future... >>> >>> right now, we need to use rand(range) + start >>> >>> and it can cause a bug that can otherwise be avoided if we have rand(m, n) >>> for the clarity. >> Why not instead suggest rand(m..n)? That would, I think, be more >> readable than rand(m, n). > > But would that draw discrete or continuous random numbers? That question actually applies to both variants. :-) The rule could probably be, if at least one of the two numbers is non int (i.e. float) then a "continuous" range is used. Alternatively we can define another function that does this ("frand" or "randf"). Btw, currently if you use a float as single parameter you still get integers back as far as I can see. Kind regards robert |
|
![]() |
| Outils de la discussion | |
|
|