Services & Resources / Wolfram Forums
-----
 /
MathGroup Archive
1995
*January
*February
*March
*April
*May
*June
*July
*August
*September
*October
*November
*December
*Archive Index
*Ask about this page
*Print this page
*Give us feedback
*Sign up for the Wolfram Insider

MathGroup Archive 1995

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

Search the Archive

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

  • To: mathgroup at christensen.cybernetics.net
  • Subject: [mg920] Re: Random[Real,{0,1},$MachinePrecision] isn't MachineNumber[] ???!!
  • From: rubin at msu.edu (Paul A. Rubin)
  • Date: Sun, 30 Apr 1995 03:54:42 -0400
  • Organization: Michigan State University

In article <3nkbjg$mq8 at news0.cybernetics.net>,
   pehowland at taz.dra.hmg.gb (Paul E. Howland) wrote:
->I've experienced the following problem with Mathematica V2.2.4 for
->OSF/1.  I'm writing a package, and want to be able to pass the desired
->precision as an option.  This will be used, amongst other things, to
->generate a Random[] number of the desired precision.  If the machine's
->own precision is being used I want to use a Compile[]'ed function on
->the random number, otherwise I want to use a pure Function[].
->
->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.
->
->Indeed, if I ask
->In[2] := MachineNumberQ[%1]
->Out[2] := False
->
->!@@?!##$%
->
->If using $MachinePrecision with Random[] doesn't give me a 
MachinePrecision
->number, what does?!
->
->However, if I use:
->In[3] := N[Random[Real,{0,1}],$MachinePrecision]
->Out[3] := 0.98857067609012
->In[4] := MachineNumberQ[%]
->Out[4] := True
->
->Note that In[1] gives me a number with 16 digits after the decimal, and
->In[3] gives me a number with 14 digits after the decimal.  However,
->the Precision[] of both is claimed to be 16, and $MachinePrecision is
->also claimed to be 16.
->
->I'm confused!
->
->Paul Howland
->Long Range Ground Radar Systems
->DRA Malvern
->UK

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

**************************************************************************
* 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)                                    *
**************************************************************************
Mathematicians are like Frenchmen:  whenever you say something to them,
they translate it into their own language, and at once it is something
entirely different.                                    J. W. v. GOETHE


  • Prev by Date: Re: Bivariate Normal Distribution
  • Next by Date: Re: Rule Writing for x and 1/x
  • Previous by thread: Re: Bivariate Normal Distribution
  • Next by thread: Re: Random[Real,{0,1},$MachinePrecision] isn't MachineNumber[] ???!!