Linux vs. Windows: different behaviour [re rand()]

This spreaded from some tests I made in connection with the thread
"Fast random string generation":

# perl -le '$,="\t"; print unpack "C*", pack "L", rand 2**32 for
1..15'
30      155     146     154
155     211     255     102
39      119     228     119
204     29      168     240
3       100     77      39
159     11      214     76
5       105     14      31
167     198     182     196
247     107     241     244
194     246     30      146
226     199     219     59
97      168     246     154
185     204     221     142
178     77      149     4
70      10      119     34

C:\TEMP>perl -le "$,=qq|\t|; print unpack 'C*', pack 'L', rand 2**32
for 1..15"
0       0       246     13
0       0       174     202
0       0       104     241
0       0       116     246
0       0       10      76
0       0       4       44
0       0       64      61
0       0       244     123
0       0       252     86
0       0       78      181
0       0       124     45
0       0       100     103
0       0       188     62
0       0       100     100
0       0       196     191


Does the cmt at the end of 'perldoc -f rand' apply? Note: 5.8.4 in
both cases (AS under Windows).


Michele
--
 {$_=pack'B8'x25,unpack'A8'x32,$a^=sub{po
p^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
.'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,

Michele Dondi <bik.mido@tiscalinet.it> wrote in
 news:4d2tn0dt15g18n5s4nlat21dbfimcfg7ba@
4ax.com:

> This spreaded from some tests I made in connection with the thread
> "Fast random string generation":
>
> # perl -le '$,="\t"; print unpack "C*", pack "L", rand 2**32 for
> 1..15'

I am not sufficiently at ease with pack to see if something is wrong
above.

> Does the cmt at the end of 'perldoc -f rand' apply? Note: 5.8.4 in
> both cases (AS under Windows).

Same version here. You got me curious. I have:

C:\Home> perl -MConfig -e"print qq{$Config{randbits}}
15

I also checked stdlib.h for the free command line compiler they have:

C:\Home> cl
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3077 for
80x86

and it says

#define RAND_MAX 0x7fff

So those are consistent.

Then, I did:

use strict;
use warnings;


my @data;
push @data, rand for 1 .. 10_000;

open my $data, '>', 'data.txt' or die "data.txt: $!";
for (@data) { print $data "$_\n" }

__END__

Five times, and looked at the resulting emprical CDF in each case, they
were all straight lines from (0,0) to (100,100) so the output rand
generates is fairly uniformly distributed.

Dunno what you are observing but I don't think the bit about

If your rand function consistently returns numbers that
are too large or too small,

applies here.

Hope this helps.

Sinan.

A. Sinan Unur wrote:

>
> C:\Home> perl -MConfig -e"print qq{$Config{randbits}}
> 15
>

Or:
perl -V:randbits

On my Linux (Mandrake-9.1) I have 48 random bits. I don't know if this
accounts for the different behaviour. (I'm not real comfortable with
'pack' either :-)

Cheers,
Rob

--
To reply by email u have to take out the u in kalinaubears.

On 26 Oct 2004 22:34:12 GMT, "A. Sinan Unur"
<1usa@llenroc.ude.invalid> wrote:
 
>
>I am not sufficiently at ease with pack to see if something is wrong
>above.

Neither am I, in the sense that I always have to check the docs, which
OTOH are clear enough. Well, at least for qw/C L/ I'm quite sure
nothing is consistently *wrong*.
 
>
>Same version here. You got me curious. I have:
>
>C:\Home> perl -MConfig -e"print qq{$Config{randbits}}
>15

Me too! (verified with 'perl -V:randbits', as suggested by another
poster.) And 48 under Linux.

>Dunno what you are observing but I don't think the bit about
>
>   If your rand function consistently returns numbers that
>   are too large or too small,
>
>applies here.

Definitely I *think* it does, in fact, with referral to my other post:

| C:\TEMP>perl -le "$,=qq|\t|; print unpack 'C*', pack 'L', rand 2**32 for 1
.15"
| 0       0       246     13
| 0       0       174     202
| 0       0       104     241
| 0       0       116     246
| 0       0       10      76
| 0       0       4       44
| 0       0       64      61
| 0       0       244     123
| 0       0       252     86
| 0       0       78      181
| 0       0       124     45
| 0       0       100     103
| 0       0       188     62
| 0       0       100     100
| 0       0       196     191

The high order bytes are always 0, and the third column values are
always even (of course this is *not* an artifact of the limited sample
- check for yourself!)


Michele
--
 {$_=pack'B8'x25,unpack'A8'x32,$a^=sub{po
p^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
.'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,

Michele Dondi <bik.mido@tiscalinet.it> wrote in
 news:40cvn0lo87cilg13t9v2tvmo3479aeert1@
4ax.com:

> On 26 Oct 2004 22:34:12 GMT, "A. Sinan Unur"
> <1usa@llenroc.ude.invalid> wrote:
> 
>
...

> Definitely I *think* it does, in fact, with referral to my other post:
>
>| C:\TEMP>perl -le "$,=qq|\t|; print unpack 'C*', pack 'L', rand 2**32
>| for 1..15" 0       0       246     13
>| 0       0       174     202

...

> The high order bytes are always 0, and the third column values are
> always even (of course this is *not* an artifact of the limited sample
> - check for yourself!)

OK, so I did this:

printf "%8.8X\n", int rand(2**32) for 1 .. 10_000;

First with AS Perl:

C:\Home> perl -v

This is perl, v5.8.4 built for MSWin32-x86-multi-thread

Here is some representative output:

6F860000 EBF20000 0E140000 28600000 02C00000 75B00000
1D140000 93260000 25960000 643C0000 CACA0000 A2800000
20980000 A0820000 94860000 B61A0000 CDE40000 ...

On the other hand,

asu1@host ~
$ perl -v

This is perl, v5.8.5 built for cygwin-thread-multi-64int

And here is some output in that case as well:

8758274B 80717716 BBCCB917 26622DE8 05D10A8A 84B2174B
1BA68432 4F146432 59605227 88D18BA6 498D9C48 788227AD
F0892E9E 9FB09C8D D2E53F9F C56B388E 0D6A6B5D 0E8CCAA1
DF68A5F0 41E118A0 ...

I would say you are right.

So, would you like to file a bug report with ActiveState :)

Sinan.