Re: Octave 2.9.16 still has failing test for randp(1e9, 1, 6)

[Jskud]

Ah Ha!  I just downloaded and recompiled 2.1.17, and randp didn't fail.
What was different?  Did the test change?  No.  Did rand.cc change?  No.
What changed?!  Oh, yeah, I did remove the FFLAGS=-O2 I had added to
"make" (since John said there was no need to override it when he
declined part of an update to INSTALL.OCTAVE).  When I put FFLAGS=-O2
back in and cleaned and recompiled, BOOM! the test failed again, and in
the same way:

octave:1>  randp("seed",1);
x = randp(1e9,1,6); 
y = [1000006208 1000012224 999981120 999963520 999963072 999981440]; 
x - y
octave:2> octave:3> octave:4> ans =

   17   27  -20   18  -19   -8

So, there's something in the Fortran code used by randp which is
sensitive to compiling with -O vs. -O2!

As an aside, I expect that most machines use IEEE floating point, and
wish we could get the same random sequences on different architectures;
I know it can be hard, given byte ordering issues.  But it can be
maddening to verify and debug modules when results vary by architecture.
And I know it doesn't help reproducibility, for numerical calculations,
that Intel has those 80 bit precision floating point registers.  But
still ....

FYI.  /Jskud

>------ Begin Included Message ------
> Date: Thu, 08 Nov 2007 14:09:53 +0100
> From: David Bateman <address@hidden>
> To: address@hidden
> CC: address@hidden
> Subject: Re: Octave 2.9.16 still has failing test for randp(1e9, 1, 6)
> 
> address@hidden wrote:
> > As reported in 
> >
> >     Debian packages for Octave 2.9.10 available in experimental
> >     - Rafael Laboissiere Mar 29, 2007; 06:35am 
> >
> > the following test was failing; and it's still failing in at least
> > 2.9.13, 2.9.15 and 2.9.16.  Here's the 2.9.16 snippet from
> > test/fntests.log:
> >
> >     >>>>> processing /usr/local/src/octave/src/DLD-FUNCTIONS/rand.cc
> >       ***** test
> >      % Test fixed state
> >      randp("seed",1);
> >      assert(randp(1e9,1,6),[1000006208 1000012224 999981120 999963520 
> > 999963072 999981440])
> >     !!!!! test failed
> >     error: assert (randp (1e9, 1, 6),[1000006208, 1000012224, 999981120, 
> > 999963520, 999963072, 999981440]) expected
> >        1.0000e+09   1.0000e+09   9.9998e+08   9.9996e+08   9.9996e+08   
> > 9.9998e+08
> >     but got
> >        1.0000e+09   1.0000e+09   9.9998e+08   9.9996e+08   9.9996e+08   
> > 9.9998e+08
> >     values do not match
> >     shared variables {
> >       __random_statistical_tests__ = 0
> >     }
> >
> > It turns out that things are only a "little bit off":
> >
> >     octave:7> randp("state",1);
> >     octave:8> assert(randp(1e9,1,6),[999915677 999976657 1000047684 
> > 1000019035 999985749 999977692],1e-6)
> >     octave:9> randp("seed",1);
> >     octave:10> x= randp(1e9,1,6); y = [1000006208 1000012224 999981120 
> > 999963520 999963072 999981440];
> >     octave:11> assert(x, y)
> >     error: assert (x,y) expected
> >        1.0000e+09   1.0000e+09   9.9998e+08   9.9996e+08   9.9996e+08   
> > 9.9998e+08
> >     but got
> >        1.0000e+09   1.0000e+09   9.9998e+08   9.9996e+08   9.9996e+08   
> > 9.9998e+08
> >     values do not match
> >     error: called from `assert' in file 
> > `/usr/local/octave/share/octave/2.9.16/m/testfun/assert.m'
> >     octave:11> x - y
> >     ans =
> >
> >        17   27  -20   18  -19   -8
> >
> > Given that there is a working test for large randp and the new "state"
> > based generator, it seems that we should change the test to match
> > current behavior.
> >
> > However, if the tests are not repeatable machine to machine (e.g., if
> > the sequence of random numbers is not going to be the same on Intel,
> > PowerPC, and Sparc 32 and 64 bit platforms), then we shouldn't be making
> > those tests (in this way), since they will fail for different platforms.
> >
> >   
> This is the case, they aren't repeatable machine to machine, though I
> thought that by reducing the length of the sequence we avoided the
> issues we were having.. Perhaps we should just be done with it and add a
> relative tolerance of 1e-6 to this test as well..
> 
> D.
> 
> 
> > /Jskud
> >
> >   
> 
> 
> -- 
> David Bateman                                address@hidden
> Motorola Labs - Paris                        +33 1 69 35 48 04 (Ph) 
> Parc Les Algorithmes, Commune de St Aubin    +33 6 72 01 06 33 (Mob) 
> 91193 Gif-Sur-Yvette FRANCE                  +33 1 69 35 77 01 (Fax) 
> 
> The information contained in this communication has been classified as: 
> 
> [x] General Business Information 
> [ ] Motorola Internal Use Only 
> [ ] Motorola Confidential Proprietary
> 
>------  End Included Message  ------