octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Jskud
Subject: Octave 2.9.16 still has failing test for randp(1e9, 1, 6)
Date: Wed, 7 Nov 2007 22:21:39 -0800

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.

/Jskud


reply via email to

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