Re: Simple Random Number Generator/Function - Cliff RNG

tomcees_math_at_yahoo.com
Date: 03/11/05 

Date: 11 Mar 2005 09:42:28 -0800

Tim and Alex:

Thanks very much for your most keen observations and detailed results.
This has certainly informed me greatly on this 'PRNG'. I will
certainly approach it with much more caution (as of course should
always be the case!).

An interesting/disturbing aside is the floating point 'performance' of
the compiler/library/processor that Tim detailed just above. While we
all live with the 'joys' of simulating real numbers on these machines,
I find that differences due to specific processor or order of operation
most disturbing. Has anyone out there studied this further? It would
be interesting to compare performance across compilers/libraries and
processors. I wonder if other languages may exhibit this sensitivity
(Java, BASICs, other Win compilers/interpreters etc.)? I only wonder
as these languages are commonly used and the casual user of these may
not be so aware of these possible sensitivities.

Bottom line here is to stick with the integers and not cloud these
PRNGs with the extra baggage of this floating point fuzziness!

Thanks again,
Tomcee

Timothy Little wrote:
> tomcees_math@yahoo.com wrote:
> > Thanks for the details. I'll try that code out. What C (C++)
compiler
> > are you using?
>
> I'm using gcc-3.2.2-5 from Red Hat 9 Linux, and glibc-2.3.2-11.9 on
an
> Athlon CPU. Using a different CPU and math library could also very
> likely affect the results, not just the compiler.
>
>
> > What are the initializers (in either single or double precision)
> > that sent it into the short and 1-cycles? I'd like to try these!
>
> In single precision, every initializer I tested, out of about 10
> million pseudo-randomly selected (with a known good PRNG), sent it
> into a cycle of at most a few hundred. In double precision such
> cycles were vastly rarer, but try 0.6912802303232153981 - it had
> x(1249) = x(2498).
>
> It turns out that most of the fixed points were 'nan' cycles obtained
> when 100*log(z) was too close to an integer eg 0.9512294245007140091.
> However, 0.47015092947070513190 produced a true fixed point. This
> value was discovered simply by trying out solutions to
z+n=-100*log(z)
> for various n, and corresponds to the closest double precision
> floating point approximation for the solution with n=75.
>
>
> Be warned though: the compiler may perform optimizations that are
> perfectly legal, but which can cause a sequence of operations to be
> done either completely internally to the CPU, or flushed to memory
and
> reloaded. With some FPUs internal floating point numbers are
> represented using greater precision than the in-memory form, and
hence
> calculations that depend critically upon the least significant bits
> may yield different results.
>
> In particular, the result of:
>
> x = fold(x);
> <do other stuff not involving x>
> x = fold(x);
>
> can be different from:
>
> x = fold(x);
> x = fold(x);
> <do other stuff not involving x>
>
> This actually happened in some of my test runs, and proved extremely
> painful to track down. The joys of floating point arithmetic. Also
a
> very good reason to avoid depending upon any particular behaviour,
> especially in an algorithm that is claimed to be portable.
>
>
> - Tim

Relevant Pages

  • Re: Im not the only one who values interval-arithmetic
    ... I see rounding mode discussed in regard to floating ... It's only used by the compiler ... name of the package and something about how it works? ... coerced to an interval by mapping NUM -> before some ...
    (comp.lang.lisp)
  • Re: Hercules
    ... Although D-format floating point does use 64 bits to represent a floating point number, I don't call the instructions which process these numbers "64-bit instructions". ... In PL/I terms, instruction I received way back when indicated that FLOAT DECwas the way to go to use E-format in the compiled code, and FLOAT DECwas the way to go to use D-format in the compiled code. ... My reference to Fujitsu was simply to record my experience that Fj had gone to the trouble of making their PL/I compiler sufficiently "plug compatible" with IBM's Optimizing compiler that ...
    (comp.lang.pl1)
  • Re: Modelling Disjoint Subtypes
    ... plus sign is represented by a floating point addition operation. ... In the case of a Java compiler, ... two multiplies (x.numerator * y.numerator, ... because temperature does not inherently have ratio. ...
    (comp.databases.theory)
  • Re: What I can to do with old PL/1 code?
    ... >> I have IBM Visual Age PL/1 compiler, ... > issues related to limitations on precision and representation of real ... > the same binary precision for all floating point numbers. ...
    (comp.lang.pl1)
  • Re: Floating Point and C casts? (was: Re: typecast internals)
    ... You are mixing a discussion of integer and floating point storage ... What particular data conversion problem are you really ... formats), but these formats are not typically implemented off the VAX ... IEEE floating point conversions are detailed in the compiler manuals ...
    (comp.os.vms)