octave-maintainers
[Top][All Lists]
Advanced

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

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


From: David Bateman
Subject: Re: generators and endian [from thread on address@hidden
Date: Fri, 23 Mar 2007 14:23:37 +0100
User-agent: Thunderbird 1.5.0.7 (X11/20060921)

Paul Kienzle wrote:
>
> On Mar 23, 2007, at 5:21 AM, David Bateman wrote:
>
>> John W. Eaton wrote:
>>> On 22-Mar-2007, Paul Kienzle wrote:
>>> | 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.
>
> I agree that generating uniforms from the mt code stably across
> platforms is not an issue.  It is the other sequences I'm concerned
> about.
>
> For example, constructing the randn ziggurat involves
> calculations such as exp(-.5*sqrt(-2*log(A/B+f[i+1])^2).  How sure
> are you that this number is going to be computed identically
> across platforms?  I know that I had to loosen a number of
> tolerances on test cases for various codes for them to pass
> on PPC OS X, so I would be surprised if these results were any
> more consistent.  Even if you do stablize the ziggurat, the tail
> test still involves -2*log(Ua) <= C^2*log(Ub)^2, and if this
> test passes on one architecture but fails on another, the remaining
> sequence will be completely different.
>
> The only way I can think of to guarantee an approximately
> repeatable sequence for a derived generator is to call pdf_inv
> for your particular probability density function.  The numbers
> won't be identical, but they should be within epsilon across
> platforms.  I'm not sure this matters though --- even if you
> had an identical sequence the simulation would still produce
> different results on different platforms due to differences
> in how the floating point is handled.
>
> I guess that leaves us with the occasionally failing statistical
> tests that started this whole thread :-(
>
>     - Paul
>
>
Then we can't guarantee the exactly same sequences across platform for
any of the sequences except rand. We can guarantee that the same
sequences with the same seed on the same platform.

In any case at this point I'd suggest just applying the two patches I
proposed and see if there are any failed tests on platforms other than
intel 32-bit... For the feedback in a previous mail, it seems that the
tests as stated with fixed sequences should be ok at least for intel
32-bit and powerPC G4's...

D.


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



reply via email to

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