MathGroup Archive 1995

[Date Index] [Thread Index] [Author Index]

Search the Archive

Re: Random[Real,{0,1},$MachinePrecision] isn't MachineNumber[] ???!!

  • To: mathgroup at
  • Subject: [mg944] Re: Random[Real,{0,1},$MachinePrecision] isn't MachineNumber[] ???!!
  • From: withoff (David Withoff)
  • Date: Wed, 3 May 1995 00:23:28 -0400
  • Organization: Wolfram Research, Inc.

In article <3nn86p$9pq at> rubin at (Paul A. Rubin) writes:
>In article <3nkbjg$mq8 at>,
>   pehowland at (Paul E. Howland) wrote:
>->When I generate a random number, with machine precision, as below
>->In[1] := Random[Real,{0,1},$MachinePrecision]
>->Out[1] := 0.3739679783533225
>->and then apply a Compile[]'ed function to it, Compile[] complains with
>->CompiledFunction::cfr: Argument `1` at position 1 should be a machine
>->sized real number.
>->I'm confused!
>->Paul Howland
>->Long Range Ground Radar Systems
>->DRA Malvern
>I did a little experiment, cranking out randoms with Random[ Real, {0, 1}, 
>$MachinePrecision ] and then "converting" them with N[] (whose default 
>precision is $MachinePrecision).  I did it on a PC running Windows, so 
>$MachinePrecision is 16.  I measured precision and accuracy of every 
>number, before and after conversion, and tested each with MachineNumberQ.  
>I only ran a few number numbers, so by chance the closest I got to 0 was 
>about 0.0044, which is pertinent.
>To summarize the results:
>  (a)  the numbers generated by Random[] always had accuracy 16, had 
>precisions from 14 to 16 (the smaller the number, the lower the precision), 
>and never passed the MachineNumberQ[] test;
>  (b)  the output from N[] always had precision 16, had accuracy from 16 to 
>18 (the smaller the number, the higher the accuracy), and always passed the 
>MachineNumberQ[] test.
>From this it would appear that the third argument to Random[] is being 
>interpreted as an accuracy target, not a precision target (the wording of 
>the textbook and on-line help notwithstanding).  In contrast, N[] 
>interprets the precision target correctly (as precision, not accuracy).  
>Now, if the output of Random[] has precision less than $MachinePrecision, 
>it stands to reason that it would fail the MachineNumberQ[] test.  The only 
>part I'm not clear on is why Random[] outputs with accuracy and precision 
>both equal to $MachinePrecision still failed the test.  More precisely (no 
>pun intended), I wonder what it is about them that allows Mma to 
>distinguish them from numbers generated by N[], also with accuracy and 
>precision equal to $MachinePrecision, which MachineNumberQ[] accepts.  It 
>must be something in the internal representation of the numbers.  Their 
>heads are Real in both cases.
>In any event, your confusion is justified.  Interpreting argument three as 
>an accuracy target is either (a) a bug, (b) a lapse in the documentation, 
>or (c) a feature.  (Unless (d) I'm misinterpreting something.)
>* Paul A. Rubin                                  Phone: (517) 432-3509   *
>* Department of Management                       Fax:   (517) 432-1111   *
>* Eli Broad Graduate School of Management        Net:   RUBIN at MSU.EDU    *
>* Michigan State University                                              *
>* East Lansing, MI  48824-1122  (USA)                                    *

The third argument in Random[Real, {min, max}, prec] specifies the
accuracy of a number between 0 and 1 that is generated as an intermediate
step in constructing the result.  In the end, however, it gives neither
the precision nor the accuracy of the result.

A good simulation for present purposes for what Random[Real, {0, 1}, 20]
is doing is

    SetAccuracy[Sum[Random[Integer, {0, 1}]/2^k, {k, 80}], 20] *
                           SetPrecision[1, 20]

which generates a bunch of of bits (more than necessary), adjusts
the number to the requested accuracy, and scales the result to fit
in the requested interval.  

The precision of the result will be determined by the number of
significant bits after the first non-zero significant bit.  The
precision will always be smaller than prec, but unless lots of
the leading bits are zero, it will only be slightly smaller.

The accuracy of the result will be determined both by the number
of significant bits and by the scale.  If the random number is
scaled to be between zero and one, then the accuracy and the
precision will be similar.  If the scale is larger or smaller than
this, then the accuracy will be the sum of the scale and the precision.

You can decide for yourself if the prec argument should be called
precision or accuracy.  I prefer precision.  It is close to giving
the precision except when lots of the leading bits of the internally
generated random number are zero, but it gives the accuracy only when
the random number is near one.  A sensible alternative design would be
for Random to produce numbers such that the accuracy was constant, but
it would definately be wrong to generate numbers with a fixed number
of significant digits (a fixed precision).

There are several other issues related to precision, accuracy, and
arithmetic that are swirling around in the original discussion, so 
this probably doesn't answer the whole question, but hopefully it
answers the part related to Random.

Dave Withoff
Research and Development
Wolfram Research

  • Prev by Date: Re: Kernel configuration for DEC Alpha on VMS
  • Next by Date: Re: Challenge!
  • Previous by thread: Re: Random[Real,{0,1},$MachinePrecision] isn't MachineNumber[] ???!!
  • Next by thread: Re: Rule Writing for x and 1/x