octave-maintainers
[Top][All Lists]
Advanced

[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: David Bateman
Subject: Re: Octave 2.9.16 still has failing test for randp(1e9, 1, 6)
Date: Sat, 10 Nov 2007 20:32:24 +0100
User-agent: Thunderbird 1.5.0.7 (X11/20060921)

address@hidden wrote:
> 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

The mersenne twister calculates everything in 32bit.. All of the
generators except randp give the same results on all architectures, and
randp only gives different results in the last couple of bits for large
values of L due to differences between architectures. Even then randp
follows the same sequence on all architectures..

D.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]