Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming > #3285 > unrolled thread

Compare two methods of random permutations

Back to article view | Back to comp.programming

Contents

  Compare two methods of random permutations Mok-Kong Shen <mok-kong.shen@t-online.de> - 2013-05-08 23:35 +0200
    Re: Compare two methods of random permutations James Dow Allen <jdallen2000@yahoo.com> - 2013-05-11 21:31 -0700
      Re: Compare two methods of random permutations Mok-Kong Shen <mok-kong.shen@t-online.de> - 2013-05-13 08:07 +0200
        Re: Compare two methods of random permutations James Dow Allen <jdallen2000@yahoo.com> - 2013-05-13 02:34 -0700
    Re: Compare two methods of random permutations Mok-Kong Shen <mok-kong.shen@t-online.de> - 2013-05-13 08:01 +0200
    Re: Compare two methods of random permutations bob <bob@coolfone.comze.com> - 2013-05-13 08:26 -0700
      Re: Compare two methods of random permutations James Dow Allen <jdallen2000@yahoo.com> - 2013-05-13 11:42 -0700
        Re: Compare two methods of random permutations bob <bob@coolfone.comze.com> - 2013-05-16 13:46 -0700
      Re: Compare two methods of random permutations Mok-Kong Shen <mok-kong.shen@t-online.de> - 2013-05-13 21:09 +0200
        Re: Compare two methods of random permutations bob <bob@coolfone.comze.com> - 2013-05-13 12:57 -0700
          Re: Compare two methods of random permutations Mok-Kong Shen <mok-kong.shen@t-online.de> - 2013-05-13 22:59 +0200
            Re: Compare two methods of random permutations bob <bob@coolfone.comze.com> - 2013-05-13 15:28 -0700
              Re: Compare two methods of random permutations Mok-Kong Shen <mok-kong.shen@t-online.de> - 2013-05-14 10:54 +0200
                Re: Compare two methods of random permutations James Dow Allen <jdallen2000@yahoo.com> - 2013-05-14 05:32 -0700
                  Re: Compare two methods of random permutations Mok-Kong Shen <mok-kong.shen@t-online.de> - 2013-05-14 22:46 +0200
                    Re: Compare two methods of random permutations James Dow Allen <jdallen2000@yahoo.com> - 2013-05-14 14:19 -0700
                      Re: Compare two methods of random permutations James Dow Allen <jdallen2000@yahoo.com> - 2013-05-14 15:06 -0700
                        Re: Compare two methods of random permutations Mok-Kong Shen <mok-kong.shen@t-online.de> - 2013-05-15 10:16 +0200
                          Re: Compare two methods of random permutations James Dow Allen <jdallen2000@yahoo.com> - 2013-05-15 03:54 -0700
                        Re: Compare two methods of random permutations Patricia Shanahan <pats@acm.org> - 2013-05-15 07:11 -0700
                          Re: Compare two methods of random permutations James Dow Allen <jdallen2000@yahoo.com> - 2013-05-15 11:04 -0700
                            Re: Compare two methods of random permutations James Dow Allen <jdallen2000@yahoo.com> - 2013-05-15 11:06 -0700
                            Re: Compare two methods of random permutations Patricia Shanahan <pats@acm.org> - 2013-05-15 12:55 -0700
                            Re: Compare two methods of random permutations "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2013-05-16 06:10 +0100
                              Re: Compare two methods of random permutations pacman@kosh.dhis.org (Alan Curry) - 2013-05-16 06:57 +0000
                                Re: Compare two methods of random permutations "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2013-05-16 09:26 +0100
                              Re: Compare two methods of random permutations James Dow Allen <jdallen2000@yahoo.com> - 2013-05-16 01:35 -0700
                                Re: Compare two methods of random permutations Mok-Kong Shen <mok-kong.shen@t-online.de> - 2013-05-17 14:11 +0200
                                  Re: Compare two methods of random permutations James Dow Allen <jdallen2000@yahoo.com> - 2013-05-17 08:13 -0700
                                    Re: Compare two methods of random permutations Mok-Kong Shen <mok-kong.shen@t-online.de> - 2013-05-19 11:06 +0200
                                      Re: Compare two methods of random permutations James Dow Allen <jdallen2000@yahoo.com> - 2013-05-19 03:14 -0700
                                        Re: Compare two methods of random permutations Mok-Kong Shen <mok-kong.shen@t-online.de> - 2013-05-19 13:26 +0200
                                          Re: Compare two methods of random permutations James Dow Allen <jdallen2000@yahoo.com> - 2013-05-19 04:59 -0700
                                            Re: Compare two methods of random permutations Mok-Kong Shen <mok-kong.shen@t-online.de> - 2013-05-19 14:13 +0200
                                              Re: Compare two methods of random permutations James Dow Allen <jdallen2000@yahoo.com> - 2013-05-19 05:52 -0700
                                                Re: Compare two methods of random permutations Mok-Kong Shen <mok-kong.shen@t-online.de> - 2013-05-19 15:06 +0200
                                                  Re: Compare two methods of random permutations James Dow Allen <jdallen2000@yahoo.com> - 2013-05-19 06:50 -0700
                                                    Re: Compare two methods of random permutations Mok-Kong Shen <mok-kong.shen@t-online.de> - 2013-05-19 16:14 +0200
                                                      Re: Compare two methods of random permutations James Dow Allen <jdallen2000@yahoo.com> - 2013-05-19 08:11 -0700
                                                        Re: Compare two methods of random permutations Mok-Kong Shen <mok-kong.shen@t-online.de> - 2013-05-19 17:15 +0200
                                                        Re: Compare two methods of random permutations Mok-Kong Shen <mok-kong.shen@t-online.de> - 2013-05-19 17:24 +0200

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#3311

On May 15, 9:11 pm, Patricia Shanahan <p...@acm.org> wrote:
> The % method does work correctly if m is a factor of n.

Duh. Yeah.  Note that the code snippet I posted assures, via
         do a = rand();
        while (a >= 1916006400);
that the requirements are met throughout.

> java.util.Random contains code to correct for this effect ...

So do my libraries.
I don't think this qualifies as "rocket science."

James

[toc] | [prev] | [next] | [standalone]

#3312

On May 16, 1:04 am, James Dow Allen <jdallen2...@yahoo.com> wrote:

> Duh. ...

And, yes, I did explain this all to OP four years ago in
   Message-ID: <34e58089-64de-4988-b50b-
bf12c7c547a6@k13g2000prh.googlegroups.com>

HTH, James

[toc] | [prev] | [next] | [standalone]

#3313

On 5/15/2013 11:04 AM, James Dow Allen wrote:
> On May 15, 9:11 pm, Patricia Shanahan <p...@acm.org> wrote:
>> The % method does work correctly if m is a factor of n.
>
> Duh. Yeah.  Note that the code snippet I posted assures, via
>           do a = rand();
>          while (a >= 1916006400);
> that the requirements are met throughout.
>
>> java.util.Random contains code to correct for this effect ...
>
> So do my libraries.
> I don't think this qualifies as "rocket science."

Ah, I see. You get a number that is uniformly distributed over the range
from 0 to 1916006400-1. 1916006400 is an integer multiple of 12!, so the
"m is a factor of n" condition is true for each remainder operation.

Patricia

[toc] | [prev] | [next] | [standalone]

#3316

James Dow Allen wrote:

> Duh. Yeah.  Note that the code snippet I posted assures, via
>          do a = rand();
>         while (a >= 1916006400);
> that the requirements are met throughout.

Missed that aspect of it myself.  Shows the value of comments in code...

But, why 1916006400 ?  I may be missing something but it seems to me that 
239500800 (12! / 2) would work just as well and not have a confusing/misleading 
factor of 8 mismatch with the code.

    -- chris 

[toc] | [prev] | [next] | [standalone]

#3317

In article <O-CdnaNSZ9AA9wnMnZ2dnUVZ8gudnZ2d@bt.com>,
Chris Uppal <chris.uppal@metagnostic.REMOVE-THIS.org> wrote:
>James Dow Allen wrote:
>
>> Duh. Yeah.  Note that the code snippet I posted assures, via
>>          do a = rand();
>>         while (a >= 1916006400);
>> that the requirements are met throughout.
>
>Missed that aspect of it myself.  Shows the value of comments in code...
>
>But, why 1916006400 ?  I may be missing something but it seems to me that 
>239500800 (12! / 2) would work just as well and not have a confusing/misleading 
>factor of 8 mismatch with the code.

Whenever rand() returns something bigger than 1916006400 you have to call it
again. And keep calling it until it gives you something good. If you lower
the limit, you'll spend more time in the loop waiting for a usable random
number.

1916006400 is the largest multiple of 239500800 that fits in a signed 32-bit
integer, so it minimizes the number of rand() results that have to be thrown
away. If your rand() doesn't return a signed 32-bit integer you should adjust
the constant accordingly.

-- 
Alan Curry

[toc] | [prev] | [next] | [standalone]

#3319

Alan Curry wrote:

> 1916006400 is the largest multiple of 239500800 that fits in a signed
> 32-bit integer, so it minimizes the number of rand() results that have to
> be thrown away.

Ah yes!  Got it now, thanks.

    -- chris 

[toc] | [prev] | [next] | [standalone]

#3320

On May 16, 12:10 pm, "Chris Uppal" <chris.up...@metagnostic.REMOVE-
THIS.org> wrote:
> James Dow Allen wrote:
> > Note that the code snippet I posted assures, via
> >          do a = rand();
> >         while (a >= 1916006400);
> > that the requirements are met throughout.
>
> Missed that aspect of it myself.  Shows the value of comments in code...

I could have written
        // 5 * 12! would be too large -- overflows RANDMAX
        while (a >= 4 * (12*11*10*9*8*7*6*5*4*3*2));
Sorry.  Still, making excuses for the inexcusable, an
alert reader would have wondered why the "while a>= " is present
at all.  Perhaps I forgot I wasn't posting in rec.puzzles.  :-)

My "real code" for such is quite different:
1) One wants to handle arbitrary random sizes, not
just 12,11,10,9, ... specifically.
2) The sample code discards unused 11% of its random
inputs.  Not only can that be reduced, but *some* of the
random "entropy" can be preserved even on the discards.

I don't know how important such coding is.
The twiddling sacrifices much of the time saved by fewer
calls to random().  Still I will post more general routines
if there's interest.  Please tell me if most people use
31-bit generators (Posix?) or 32-bit generators (Marsaglia).
Yes, I know about "#ifdef" -- I just don't like to
post cluttered code.

James

[toc] | [prev] | [next] | [standalone]

#3324

Am 16.05.2013 10:35, schrieb James Dow Allen:
> On May 16, 12:10 pm, "Chris Uppal" <chris.up...@metagnostic.REMOVE-
> THIS.org> wrote:
>> James Dow Allen wrote:
>>> Note that the code snippet I posted assures, via
>>>           do a = rand();
>>>          while (a >= 1916006400);
>>> that the requirements are met throughout.
>>
>> Missed that aspect of it myself.  Shows the value of comments in code...
>
> I could have written
>          // 5 * 12! would be too large -- overflows RANDMAX
>          while (a >= 4 * (12*11*10*9*8*7*6*5*4*3*2));
> Sorry.  Still, making excuses for the inexcusable, an
> alert reader would have wondered why the "while a>= " is present
> at all.  Perhaps I forgot I wasn't posting in rec.puzzles.  :-)
>
> My "real code" for such is quite different:
> 1) One wants to handle arbitrary random sizes, not
> just 12,11,10,9, ... specifically.
> 2) The sample code discards unused 11% of its random
> inputs.  Not only can that be reduced, but *some* of the
> random "entropy" can be preserved even on the discards.
>
> I don't know how important such coding is.
> The twiddling sacrifices much of the time saved by fewer
> calls to random().  Still I will post more general routines
> if there's interest.  Please tell me if most people use
> 31-bit generators (Posix?) or 32-bit generators (Marsaglia).
> Yes, I know about "#ifdef" -- I just don't like to
> post cluttered code.

I suppose one has first to know in which range is rand()
(assumed to be) a uniformly distributed random variable. Could
you tell? Further, could you at least give a sketch of what you
indicated to be more general constructs of your design?

M. K. Shen

[toc] | [prev] | [next] | [standalone]

#3325

On May 17, 7:11 pm, Mok-Kong Shen <mok-kong.s...@t-online.de> wrote:
> I suppose one has first to know in which range is rand()
> (assumed to be) a uniformly distributed random variable. Could
> you tell? Further, could you at least give a sketch of what you
> indicated to be more general constructs of your design?

The method maintains variables a, b
where a is known to be a uniform variate
on {0, 1, 2, ..., b-1}
Initially, a=0, b=1.

To replenish when b becomes small, perform
    b <-- b * 2^16
    a <-- a * 2^16 + (16 random bits)
(The "16" is arbitrary example.  Details may vary
according to word size and random() spec.)

To output a uniform variate on {0, 1, ..., N-1}
  Retry:
    q <-- a / N
    r <-- a % N
    m <-- b / N
    If  m == q Then
          b = b % N
          a = r
          Replenish
          goto Retry
    Else
          a = q
          b = m
          Return r

(Sorry if I've slipped translating from C to pseudo.  ::whack:: )
Note that much of the division overhead is necessary in
any method, at least for "perfect" randoms.

Applications for such a method may be rare (though
not non-existent).
There are very fast medium-quality PRNG's good enough
for most applications when crypto-security is unneeded.
No one need bother with the method unless the PRNG
is slowish.

James

[toc] | [prev] | [next] | [standalone]

#3335

Am 17.05.2013 17:13, schrieb James Dow Allen:
> On May 17, 7:11 pm, Mok-Kong Shen <mok-kong.s...@t-online.de> wrote:
>> I suppose one has first to know in which range is rand()
>> (assumed to be) a uniformly distributed random variable. Could
>> you tell? Further, could you at least give a sketch of what you
>> indicated to be more general constructs of your design?
>
> The method maintains variables a, b
> where a is known to be a uniform variate
> on {0, 1, 2, ..., b-1}
> Initially, a=0, b=1.
[snip]

My first question was: You use rand(), presumably from
a certain programming language and that is fixed/unique
at least for a given compiler. Does one know in which
range [0, b-1] is rand() a uniform variate?

M. K. Shen

[toc] | [prev] | [next] | [standalone]

#3337

On May 19, 4:06 pm, Mok-Kong Shen <mok-kong.s...@t-online.de> wrote:
> Am 17.05.2013 17:13, schrieb James Dow Allen:> On May 17, 7:11 pm, Mok-Kong Shen <mok-kong.s...@t-online.de> wrote:
> > The method maintains variables a, b
> > where a is known to be a uniform variate
> > on {0, 1, 2, ..., b-1}
> > Initially, a=0, b=1.
>
> My first question was: You use rand(), presumably from
> a certain programming language and that is fixed/unique
> at least for a given compiler. Does one know in which
> range [0, b-1] is rand() a uniform variate?

From your question, I'm afraid you failed to understand
my method.  :-(

Anyway, for POSIX systems, rand() is uniform on
  (0, 1, ..., RANDMAX}
HOWEVER, simplest, when you want best control and flexibility
is to link a specific PRNG into your application.
There are several such with source code easily found on-line.
Most return from {0, 1, ..., 2^32 - 1}

HOWEVER, this is unrelated to {0, ..., b-1} in the description
of the method I posted.  That method maintains a variate
of ever-diminishing range, replenishing it by calling a PRNG
when the range becomes too small.
Hence the b in that description is variable.

James

[toc] | [prev] | [next] | [standalone]

#3340

Am 19.05.2013 12:14, schrieb James Dow Allen:
> On May 19, 4:06 pm, Mok-Kong Shen <mok-kong.s...@t-online.de> wrote:
>> Am 17.05.2013 17:13, schrieb James Dow Allen:> On May 17, 7:11 pm, Mok-Kong Shen <mok-kong.s...@t-online.de> wrote:
>>> The method maintains variables a, b
>>> where a is known to be a uniform variate
>>> on {0, 1, 2, ..., b-1}
>>> Initially, a=0, b=1.
>>
>> My first question was: You use rand(), presumably from
>> a certain programming language and that is fixed/unique
>> at least for a given compiler. Does one know in which
>> range [0, b-1] is rand() a uniform variate?
>
>  From your question, I'm afraid you failed to understand
> my method.  :-(
>
> Anyway, for POSIX systems, rand() is uniform on
>    (0, 1, ..., RANDMAX}
> HOWEVER, simplest, when you want best control and flexibility
> is to link a specific PRNG into your application.
> There are several such with source code easily found on-line.
> Most return from {0, 1, ..., 2^32 - 1}
>
> HOWEVER, this is unrelated to {0, ..., b-1} in the description
> of the method I posted.  That method maintains a variate
> of ever-diminishing range, replenishing it by calling a PRNG
> when the range becomes too small.
> Hence the b in that description is variable.

But you do first get a number, say, R, from rand(), don't you?
If so, I think (at least till now) that the range of R, in
which R is (assumed to be) a uniform random variate, is of
significance.

Suppose now that R is uniformly distributed in [0, 2^32-1]. Then
as clearly shown in the post of Patricia Shanahan, one couldn't
"simply" use R%m to get a value that is uniformly distributed in
[0, m-1] for arbitrary m (which was my point of argument 4 years ago).

M. K. Shen

[toc] | [prev] | [next] | [standalone]

#3341

On May 19, 6:26 pm, Mok-Kong Shen <mok-kong.s...@t-online.de> wrote:
> Am 19.05.2013 12:14, schrieb James Dow Allen:

> as clearly shown in the post of Patricia Shanahan, one couldn't
> "simply" use R%m to get a value that is uniformly distributed in
> [0, m-1] for arbitrary m (which was my point of argument 4 years ago).

And you're still wrong.  Examine, with both eyes, EITHER the snippet
I posted 4 days ago, or the pseudo-code I posted three days ago.
Either of them deals with your objection.
Patricia figured it out.  See if you can.
... I'm losing patience.

James

[toc] | [prev] | [next] | [standalone]

#3342

Am 19.05.2013 13:59, schrieb James Dow Allen:
> On May 19, 6:26 pm, Mok-Kong Shen <mok-kong.s...@t-online.de> wrote:
>> Am 19.05.2013 12:14, schrieb James Dow Allen:
>
>> as clearly shown in the post of Patricia Shanahan, one couldn't
>> "simply" use R%m to get a value that is uniformly distributed in
>> [0, m-1] for arbitrary m (which was my point of argument 4 years ago).
>
> And you're still wrong.  Examine, with both eyes, EITHER the snippet
> I posted 4 days ago, or the pseudo-code I posted three days ago.
> Either of them deals with your objection.
> Patricia figured it out.  See if you can.
> ... I'm losing patience.

Let's be in details. Do you mean the following code?

do a = rand();
while (a >= 4 * (12*11*10*9*8*7*6*5*4*3*2));

Do you still maintain that, if a is (assumed to be uniform in
[0, 2^32-1], one could (theoretically correctly) get a uniformly
distributed random value in [0, m-1] for arbitrary m (e.g. 11),
with a%m? (Patricia Shanahan showed namely that one can't.)

M. K. Shen

[toc] | [prev] | [next] | [standalone]

#3343

On May 19, 7:13 pm, Mok-Kong Shen <mok-kong.s...@t-online.de> wrote:
> Am 19.05.2013 13:59, schrieb James Dow Allen:
> > ... I'm losing patience.

One LAST try.

> with a%m? (Patricia Shanahan showed namely that one can't.)

No.  Patricia overlooked the "while (a >= 4 * Factorial 15)
and revised her comment when it was pointed out.

This is my final effort.  Pay attention.

You need a random number on {1,2,3,4,5} but all you have
for generator is a 6-sided die.  What do you do?
Devise a solution before reading on.

.

.

.

..

Spoiler follows.

,

,

,

,

,

,

Roll the die.  Accept any of {1,2,3,4,5}
But roll again if you get 6.

That's what my code does.  That's what
my code did 4 years ago.  That's how
everyone does it.

Does this help?

James

[toc] | [prev] | [next] | [standalone]

#3344

Am 19.05.2013 14:52, schrieb James Dow Allen:
> On May 19, 7:13 pm, Mok-Kong Shen <mok-kong.s...@t-online.de> wrote:
>> Am 19.05.2013 13:59, schrieb James Dow Allen:
>>> ... I'm losing patience.
>
> One LAST try.
>
>> with a%m? (Patricia Shanahan showed namely that one can't.)
>
> No.  Patricia overlooked the "while (a >= 4 * Factorial 15)
> and revised her comment when it was pointed out.
>
> This is my final effort.  Pay attention.
[skip]

I overlooked. I see your scheme. But for e.g. n=52 (cf. card games)
what kind of rand() would you need?

M. K. Shen

[toc] | [prev] | [next] | [standalone]

#3345

On May 19, 8:06 pm, Mok-Kong Shen <mok-kong.s...@t-online.de> wrote:
> Am 19.05.2013 14:52, schrieb James Dow Allen:> On May 19, 7:13 pm, Mok-Kong Shen <mok-kong.s...@t-online.de> wrote:
> >> Am 19.05.2013 13:59, schrieb James Dow Allen:
> >>> ... I'm losing patience.
>
> > One LAST try.
>
> >> with a%m? (Patricia Shanahan showed namely that one can't.)
>
> > No.  Patricia overlooked the "while (a >= 4 * Factorial 15)
> > and revised her comment when it was pointed out.
>
> > This is my final effort.  Pay attention.
>
> [skip]
>
> I overlooked. I see your scheme. But for e.g. n=52 (cf. card games)
> what kind of rand() would you need?
>
> M. K. Shen

Use the scheme I show in
Message-ID: <d40069e8-8b3d-4514-877f-
d50c7bef874b@pd6g2000pbc.googlegroups.com>
with N taking the values 52, 51, 50, ...
(Fisher-Yates).

ANY PRNG (rand()) can be used for the replenishing.
Most straightforward might be to grab a good 32-bit
PRNG (e.g. Mersenne Twister) off the Internet.
In that case you might use the pseudo-code as is,
with its 16-bit replenish.  (Please don't tell me you
need help satisfying TWO invocations of 16-bit
replenish with ONE call to the 32-bit PRNG.)

James

[toc] | [prev] | [next] | [standalone]

#3346

Am 19.05.2013 15:50, schrieb James Dow Allen:
> On May 19, 8:06 pm, Mok-Kong Shen <mok-kong.s...@t-online.de> wrote:
>> Am 19.05.2013 14:52, schrieb James Dow Allen:> On May 19, 7:13 pm, Mok-Kong Shen <mok-kong.s...@t-online.de> wrote:
>>>> Am 19.05.2013 13:59, schrieb James Dow Allen:
>>>>> ... I'm losing patience.
>>
>>> One LAST try.
>>
>>>> with a%m? (Patricia Shanahan showed namely that one can't.)
>>
>>> No.  Patricia overlooked the "while (a >= 4 * Factorial 15)
>>> and revised her comment when it was pointed out.
>>
>>> This is my final effort.  Pay attention.
>>
>> [skip]
>>
>> I overlooked. I see your scheme. But for e.g. n=52 (cf. card games)
>> what kind of rand() would you need?
>>
>> M. K. Shen
>
> Use the scheme I show in
> Message-ID: <d40069e8-8b3d-4514-877f-
> d50c7bef874b@pd6g2000pbc.googlegroups.com>
> with N taking the values 52, 51, 50, ...
> (Fisher-Yates).
>
> ANY PRNG (rand()) can be used for the replenishing.
> Most straightforward might be to grab a good 32-bit
> PRNG (e.g. Mersenne Twister) off the Internet.
> In that case you might use the pseudo-code as is,
> with its 16-bit replenish.  (Please don't tell me you
> need help satisfying TWO invocations of 16-bit
> replenish with ONE call to the 32-bit PRNG.)

But then you are returning to the common Fisher and
Yates scheme, which employs generally a good PRNG
returning a PRN in [0, 1) as real numbers, as explained
in Knuth's book. That's nothing new, isn't it?

M. K. Shen

[toc] | [prev] | [next] | [standalone]

#3347

On May 19, 9:14 pm, Mok-Kong Shen <mok-kong.s...@t-online.de> wrote:
> But then you are returning to the common Fisher and
> Yates scheme, which employs generally a good PRNG
> returning a PRN in [0, 1) as real numbers, as explained
> in Knuth's book. That's nothing new, isn't it?
>
> M. K. Shen

Invoke the PRNG 8 times instead of 51 times.
What were you trying to do anyway, do
you even remember?

[toc] | [prev] | [next] | [standalone]

#3348

Am 19.05.2013 17:11, schrieb James Dow Allen:
> On May 19, 9:14 pm, Mok-Kong Shen <mok-kong.s...@t-online.de> wrote:
>> But then you are returning to the common Fisher and
>> Yates scheme, which employs generally a good PRNG
>> returning a PRN in [0, 1) as real numbers, as explained
>> in Knuth's book. That's nothing new, isn't it?
>>
>> M. K. Shen
>
> Invoke the PRNG 8 times instead of 51 times.
> What were you trying to do anyway, do
> you even remember?

Do you have a "different" while-clause in the 8 invocations?
(You haven't anyway treated this, if I don't err.)

M. K. Shen

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.programming

csiph-web