Re: [OctDev] randn() broken

[David B. <Dav...@mo...>]

Dapr=E8s Justus Piater <Jus...@UL...> (le 08/11/2004):
> > I can't regenerate this problem with octave-forge CVS or with 2004.09=
.09.
> > I used the commands
> >
> > octave:1> hist(randn(1,1e6),-3.75:0.5:3.75)
> > octave:2> var(randn(1,1e6))
> > ans =3D 1.0001
> > octave:3> mean(randn(1,1e6))
> > ans =3D  -4.9951e-04
>=20
> This does not give enough resolution to demonstrate the problem, nor
> does it visualize temporal dependencies. However, randn() from
> octave-forge-2004.09.09, does give me a wrong

I also tried your dots command and got a clean distribution.

> octave> randn("seed", 12345);
> octave> var(randn(1,1e6))
> ans =3D 0.71239

So you clearly have a real problem.

> I append printouts of the output of the following sequence of
> commands:
>=20
> octave> randn("seed", 12345);
> octave> plot(1:10000, randn(1, 10000), ".");
> octave> print("-depsc2", "randn-dots.eps");
> octave> randn("seed", 12345);
> octave> hist(randn(1,1e6),-3.75:0.001:3.75);
> octave> print("-depsc2", "randn-hist.eps");
>=20
> The second figure suggests that the output of randn() possibly
> converges to normal over very long sequences of random numbers (albeit
> with a wrong variance), but notice the ditch at zero that persists
> even after 6 million samples.
>=20
> The non-normality is revealed by the first figure that demonstrates
> that the samples are nowhere near Gaussian for sample sizes of at
> least up to several thousands, due to a strange sequential clustering
> effect.
>=20
> I also append the counterparts of these figures using the randn() from
> octave-2.1.57, which do not exhibit these problems (but, incidentally,
> there are strange tails in the histograms).
>=20
> > before doing your test and seed if it helps. It might also be a build
> > issue, so can you try with the "-DALLBITS" flag or without it and
> > see if it makes a difference if 32 or 64 bit ints are used.
>=20
> For info, my rand.cc from octave-forge/FIXES was compiled with
> -DALLBITS (the default). I don't have the time right now to
> investigate more deeply, but will later if nobody else can reproduce
> the problem.

I tried on my side with and without -DALLBITS and could not generate the
problem... So without confirmation I think the only way to resolve this i=
s
if you try to do it.. I'd suggest a first steps are to try with and witho=
ut
-DALLBITS and also to do the same style of tests on rand to see if it has
the same behaviour. This will allow confirmation of whether the problem
is in the ziggurat code that forms the normal distribution, or in the
underlying random integer (32- or 53-bit) generators.

Regards
David

--=20
David Bateman                                Dav...@mo...
Motorola CRM                                 +33 1 69 35 48 04 (Ph)=20
Parc Les Algorithmes, Commune de St Aubin    +33 1 69 35 77 01 (Fax)=20
91193 Gif-Sur-Yvette FRANCE

The information contained in this communication has been classified as:=20

[x] General Business Information=20
[ ] Motorola Internal Use Only=20
[ ] Motorola Confidential Proprietary