[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Octave 2.9.16 still has failing test for randp(1e9, 1, 6)
From: |
Jskud |
Subject: |
Re: Octave 2.9.16 still has failing test for randp(1e9, 1, 6) |
Date: |
Sat, 10 Nov 2007 08:48:56 -0800 |
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 ------