Re: generators and endian [from thread on address@hidden

[David Bateman]

John W. Eaton wrote:
> On 22-Mar-2007, Paul Kienzle wrote:
>
> | 
> | On Mar 22, 2007, at 1:55 PM, John W. Eaton wrote:
> | 
> | > On 22-Mar-2007, David Bateman wrote:
> | >
> | > | I'd say the option 3) is probably the best, but means the old 
> | > generators
> | > | won't generator the same sequence as previously on big-endian
> | > | machines... Is this an issue?
> | >
> | > I think it is probably more important for Octave generate the same
> | > sequence for a given seed on both big and little endian systems than
> | > to preserve some old (and possibly even buggy) behavior.
> | 
> | This presents an excellent opportunity to toss the old generators,
> | at least on big-endian machines.  Any reason to keep them?
>
> Maybe we should keep a "seed" option (in addition to the new "state"
> option) for old code?
>   

This is the situation at the moment. If you don't define a seed/state or
if you define a state you have the new generators. If you define a seed
you get the old generators..

> | How much effort is it worth to guarantee that randn and other
> | derived generators produce the same sequence?  The vagaries
> | of the optimizer may mean that guard bits allow one threshold
> | test to pass on some versions of the compiler but not in others.
> | Should we force numbers to memory to clear the guard?
>
> I don't know.  I was assuming it would be a simple change.  If not,
> then I don't think it is very important for the old generators.
>   
I'm not sure this is an issue as we only work on 32 bit integers in the
base generator on which all the others are based, and then only with
shift/add operators. The other generators are then just mapping (in one
manner or another) from these integers to floats. So I'm not sure
vagaries of the guard bit come into play, at least not with the new
generators.

The issue at the moment is that for as long as the old generators have
been seeded in the manner in which they currently are, big and little
endian machine produce different sequences from the same seed. Therefore
the proposed patch I made for the "make check" code against fixed random
sequences fails on big endian machines. This only applies to the old
generators.

Long term there are three possible solutions

1) Completely remove the old generators as Paul suggested. John's stated
he's been against this in the past,

2) Fix the test code so that it tests different sequences for big and
little endian machines. This means that big and little endian machines
will keep the same sequences as they currently have, but will continue
to produce different sequences from the same seed,

3) Fix the seeding code, so that big and little endian machines produce
the same sequence.. This is how the code should always have been, as it
allows a piece of code that sets the seed to produce consistent results
across platforms. However, after at least 10 years of the current
behavior changing the sequence for a particular seed on big endian
machines is also an issue.

I tend to think that 3) is the best solution as it is what should always
have been done, and that in general the old generators are deprecated in
favor of the new generator. It also allows those with little endian
machines (the vast majority) to still produce the same sequences with
the old generators and the "seed" option as they always have.

The patch to implement 3) is fairly trivial (see the attached patch).
This together with the patch I sent in

http://www.cae.wisc.edu/pipermail/bug-octave/2007-March/001911.html

should completely address at least the current issue...

Regards
Davi


> jwe
>
>   


-- 
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

*** ./liboctave/oct-rand.cc.orig59      2007-02-18 14:51:47.000000000 +0100
--- ./liboctave/oct-rand.cc     2007-03-23 10:14:13.877012124 +0100
***************
*** 36,41 ****
--- 36,42 ----
  #include "randmtzig.h"
  #include "randpoisson.h"
  #include "randgamma.h"
+ #include "mach-info.h"
  
  // Possible distributions of random numbers.  This was handled with an
  // enum, but unwind_protecting that doesn't work so well.
***************
*** 152,158 ****
  
    union d2i { double d; octave_idx_type i[2]; };
    union d2i u;
!   F77_FUNC (getsd, GETSD) (u.i[0], u.i[1]);
    return u.d;
  }
  
--- 153,171 ----
  
    union d2i { double d; octave_idx_type i[2]; };
    union d2i u;
!     
!   oct_mach_info::float_format ff = oct_mach_info::native_float_format ();
! 
!   switch (ff)
!     {
!     case oct_mach_info::flt_fmt_ieee_big_endian:
!       F77_FUNC (getsd, GETSD) (u.i[1], u.i[0]);
!       break;
!     default:
!       F77_FUNC (getsd, GETSD) (u.i[0], u.i[1]);
!       break;
!     }
! 
    return u.d;
  }
  
***************
*** 162,172 ****
    use_old_generators = true;
    maybe_initialize ();
  
    union d2i { double d; octave_idx_type i[2]; };
    union d2i u;
    u.d = s;
!   int i0 = force_to_fit_range (u.i[0], 1, 2147483563);
!   int i1 = force_to_fit_range (u.i[1], 1, 2147483399);
    F77_FUNC (setsd, SETSD) (i0, i1);
  }
  
--- 175,199 ----
    use_old_generators = true;
    maybe_initialize ();
  
+   int i0, i1;
    union d2i { double d; octave_idx_type i[2]; };
    union d2i u;
    u.d = s;
! 
!   oct_mach_info::float_format ff = oct_mach_info::native_float_format ();
! 
!   switch (ff)
!     {
!     case oct_mach_info::flt_fmt_ieee_big_endian:
!       i1 = force_to_fit_range (u.i[0], 1, 2147483563);
!       i0 = force_to_fit_range (u.i[1], 1, 2147483399);
!       break;
!     default:
!       i0 = force_to_fit_range (u.i[0], 1, 2147483563);
!       i1 = force_to_fit_range (u.i[1], 1, 2147483399);
!       break;
!     }
! 
    F77_FUNC (setsd, SETSD) (i0, i1);
  }