randomnumbersin c_bygeorgemarsaglia_etc.htm

QPSK环境下的仿真性能分析

These should work (aside the possibility of clashing with local names)

#define SHR3  (jsr=jsr^(jsr<<17), jsr=jsr^(jsr>>13), jsr=jsr^(jsr<<5))
#define LFIB4 (t[c] = t[c]+t[c+58]+t[c+119]+t[c+179], t[++c])
#define SWB   (x = t[c+15], t[c+237] = x-(y=t[c+1]+(x<y)), t[++c])

Dmitri

[e-mail] (Radford Neal) writes:

> >George Marsaglia <[e-mail]> writes:
> >
> >> #define LFIB4 (t[c]=t[c]+t[c+58]+t[c+119]+t[c+178],t[++c])
> >> #define SWB   (t[c+237]=(x=t[c+15])-(y=t[c]+(x<y)),t[++c])
> >
> 
> In article <[e-mail]>,
> Dmitri Zaykin <[e-mail]> wrote:
> 
> >Shouldn't these be
> >
> >#define LFIB4 (t[c]=t[c]+t[c+58]+t[c+119]+t[c+179], ++c)
> >#define SWB   (t[c+237]=(x=t[c+15])-(y=t[c+1]+(x<y)), ++c)
> >
> 
> This doesn't work either.  I believe that it is undefined whether the
> comparison x<y uses the new or the old value of x.  The SHR3 macro
> in the original source also suffers from this flaw.


<HR><A NAME = "[e-mail]"></A>
Subject: Re: Random numbers for C: Improvements.
Date: 17 Jan 1999 08:06:29 PST
From: Ramin Sina &LT;[e-mail]>
Message-ID: &LT;[e-mail]>
References: <A HREF = "#[e-mail]">&LT;[e-mail]></A>
Newsgroups: sci.math,sci.math.num-analysis,sci.stat.math
Lines: 34

Dmitri Zaykin wrote:

> These should work (aside the possibility of clashing with local names)
>
> #define SHR3  (jsr=jsr^(jsr&LT;&LT;17), jsr=jsr^(jsr>>13), jsr=jsr^(jsr&LT;&LT;5))
> #define LFIB4 (t[c] = t[c]+t[c+58]+t[c+119]+t[c+179], t[++c])
> #define SWB   (x = t[c+15], t[c+237] = x-(y=t[c+1]+(x&LT;y)), t[++c])
>
> Dmitri
>
> [e-mail] (Radford Neal) writes:
>
> > >George Marsaglia &LT;[e-mail]> writes:
> > >
> > >> #define LFIB4 (t[c]=t[c]+t[c+58]+t[c+119]+t[c+178],t[++c])
> > >> #define SWB   (t[c+237]=(x=t[c+15])-(y=t[c]+(x&LT;y)),t[++c])
> > >
> >
> >

Could someone please post a short example code on how to use these in
practice. I am lost in the discussion in this thread, but I would like
very much to understand how to use these for example to generate 1000
uniform random numbers between betwen A and B ( say 5 and 10) .

Thanks very much,
Ramin Sina

--
--------------------------------------------------------
 Ramin Sina                         [e-mail]




<HR><A NAME = "77vrbs$pmj$[e-mail]"></A>
Subject: Re: Random numbers for C: Improvements.
Date: 18 Jan 1999 17:34:52 GMT
From: [e-mail] (Ed Hook)
Message-ID: &LT;77vrbs$pmj$[e-mail]>
References: <A HREF = "#[e-mail]">&LT;[e-mail]></A>
Newsgroups: sci.math,sci.math.num-analysis,sci.stat.math
Lines: 25

In article &LT;[e-mail]>,
               [e-mail] (Dmitri Zaykin) writes:
|> These should work (aside the possibility of clashing with local names)
|> 
|> #define SHR3  (jsr=jsr^(jsr&LT;&LT;17), jsr=jsr^(jsr>>13), jsr=jsr^(jsr&LT;&LT;5))
|> #define LFIB4 (t[c] = t[c]+t[c+58]+t[c+119]+t[c+179], t[++c])
|> #define SWB   (x = t[c+15], t[c+237] = x-(y=t[c+1]+(x&LT;y)), t[++c])
|> 
|> Dmitri
|> 

   No -- 'SHR3' and 'LFIB4' are OK, but your version of 'SWB'
   still invokes the dreaded undefined behavior. In the second
   calculation, there's no sequence point to separate the use
   of 'y' to determine the value of 'x&LT;y' and the assignment to 'y'.
   One might argue that this is not particularly relevant, since
   we're trying to simulate randomness anyhow ... except that, once
   undefined behavior rears its ugly head, the code is allowed to
   simply dump core and die ... 

-- 
 Ed Hook                              |       Copula eam, se non posit
 MRJ Technology Solutions, Inc.       |         acceptera jocularum.
 NAS, NASA Ames Research Center       | I can barely speak for myself, much 
 Internet: [e-mail]          |         less for my employer

<HR><A NAME = "78207l$1l8$[e-mail]"></A>
Subject: Re: Random numbers for C: Improvements.
Date: 19 Jan 1999 13:10:13 GMT
From: [e-mail] (Orjan Johansen)
Message-ID: &LT;78207l$1l8$[e-mail]>
References: <A HREF = "#77vrbs$pmj$[e-mail]">&LT;77vrbs$pmj$[e-mail]></A>
Newsgroups: sci.math,sci.math.num-analysis,sci.stat.math
Lines: 21

In article &LT;77vrbs$pmj$[e-mail]>,
Ed Hook &LT;[e-mail]> wrote:
>In article &LT;[e-mail]>,
>               [e-mail] (Dmitri Zaykin) writes:
[snip]
>|> #define SWB   (x = t[c+15], t[c+237] = x-(y=t[c+1]+(x&LT;y)), t[++c])
[snip]
>   No -- 'SHR3' and 'LFIB4' are OK, but your version of 'SWB'
>   still invokes the dreaded undefined behavior. In the second
>   calculation, there's no sequence point to separate the use
>   of 'y' to determine the value of 'x&LT;y' and the assignment to 'y'.
[snip]

I am not a programmer by trade, but I have a little knowledge of C.
Surely in an expression of the form y=..., the evaluation of ... is
guaranteed to happen before the assignment.  As far as I understand,
what is not guaranteed is that any assignments in ... would happen
before the one to y.

Greetings,
豶jan.

<HR><A NAME = "[e-mail]"></A>
Subject: Re: Random numbers for C: Improvements.
Date: Tue, 19 Jan 1999 18:29:34 GMT
From: [e-mail] (Horst Kraemer)
Message-ID: &LT;[e-mail]>
References: <A HREF = "#77vrbs$pmj$[e-mail]">&LT;77vrbs$pmj$[e-mail]></A>
Newsgroups: sci.math,sci.math.num-analysis,sci.stat.math
Lines: 39

On 18 Jan 1999 17:34:52 GMT, [e-mail] (Ed Hook) wrote:

> In article &LT;[e-mail]>,
>                [e-mail] (Dmitri Zaykin) writes:
> |> These should work (aside the possibility of clashing with local names)
> |> 
> |> #define SHR3  (jsr=jsr^(jsr&LT;&LT;17), jsr=jsr^(jsr>>13), jsr=jsr^(jsr&LT;&LT;5))
> |> #define LFIB4 (t[c] = t[c]+t[c+58]+t[c+119]+t[c+179], t[++c])
> |> #define SWB   (x = t[c+15], t[c+237] = x-(y=t[c+1]+(x&LT;y)), t[++c])
> |> 
> |> Dmitri
> |> 
> 
>    No -- 'SHR3' and 'LFIB4' are OK, but your version of 'SWB'
>    still invokes the dreaded undefined behavior. In the second
>    calculation, there's no sequence point to separate the use
>    of 'y' to determine the value of 'x&LT;y' and the assignment to 'y'.


Sorry. No sequence point is needed between reading an writing to an
lvalue.

According to your theory

	y = y - 1

would produce undefined behaviour, too ....

What produces undefined behaviour in C is _modifying_ an lvalue more
than once between the last and next sequence point. There is only one
modification of y in the expression

	 t[c+237] = x-(y=t[c+1]+(x&LT;y))



Regards
Horst


<HR><A NAME = "77t9ot$[e-mail]"></A>
Subject: Re: Random numbers for C: Improvements.
Date: 17 Jan 1999 13:22:21 -0500
From: [e-mail] (Herman Rubin)
Message-ID: &LT;77t9ot$[e-mail]>
References: <A HREF = "#[e-mail]">&LT;[e-mail]></A>
Newsgroups: sci.math,sci.math.num-analysis,sci.stat.math
Lines: 49

In article &LT;[e-mail]>,
Radford Neal &LT;[e-mail]> wrote:
>>George Marsaglia &LT;[e-mail]> writes:

>>> #define LFIB4 (t[c]=t[c]+t[c+58]+t[c+119]+t[c+178],t[++c])
>>> #define SWB   (t[c+237]=(x=t[c+15])-(y=t[c]+(x&LT;y)),t[++c])


>In article &LT;[e-mail]>,
>Dmitri Zaykin &LT;[e-mail]> wrote:

>>Shouldn't these be

>>#define LFIB4 (t[c]=t[c]+t[c+58]+t[c+119]+t[c+179], ++c)
>>#define SWB   (t[c+237]=(x=t[c+15])-(y=t[c+1]+(x&LT;y)), ++c)


>This doesn't work either.  I believe that it is undefined whether the
>comparison x&LT;y uses the new or the old value of x.  The SHR3 macro
>in the original source also suffers from this flaw.

>I think one needs to face up to an unpleasant truth:  The #define 
>facility of C was poorly designed, and is incapable in general of
>supporting the definition of "in-line" procedures.  It is far better
>to simply write ordinary C procedures, and accept the fairly small
>procedure call overhead.

I think it should be clarified, and probably written out in some
more detail.  But the procedure call overhead would be comparable
to the computing cost; C, and all other languages, have such great
built-in inefficiencies that what is needed is something written
from the standpoint of mathematics and efficiency.  

But even the use of a comparison is a costly operation, if the
result is to be used promptly.  Any form of random, pseudo-random,
or quasi-random numbers should be done in good integer form, 
not present now on many machines because of bad design coming 
from bad languages which have thrown out the natural properties
of computers, and attempts to keep stupid people from making
mistakes.  An idiot-proof language is only for idiots.




-- 
This address is for information only.  I do not claim that these views
are those of the Statistics Department or of Purdue University.
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
[e-mail]         Phone: [phone]   FAX: [phone]

<HR><A NAME = "[e-mail]"></A>
Subject: Re: Random numbers for C: Improvements.
Date: Sun, 17 Jan 1999 19:10:01 GMT
From: [e-mail] (Duncan Murdoch)
Message-ID: &LT;[e-mail]>
References: <A HREF = "#77t9ot$[e-mail]">&LT;77t9ot$[e-mail]></A>
Newsgroups: sci.stat.math
Lines: 27

On 17 Jan 1999 13:22:21 -0500, [e-mail] (Herman Rubin)
wrote:
>  But the procedure call overhead would be comparable
>to the computing cost; 

I don't know if that's true or not, but I don't think it is really
something to worry about.  The uniform value coming out of these
macros is unlikely to be the end of the computation; you'll almost
certainly do far more costly things with it after it's generated.  So
halving or doubling the speed of the generator won't have nearly so
much impact on the overall calculation.

On the other hand, if it's programmed in a way that is sometimes
incorrect in hard to detect ways, it might invalidate the whole
calculation.  That seems like a much higher cost to pay.

>An idiot-proof language is only for idiots.

No, if such a thing existed, it would also reduce the occasional
lapses of non-idiots.  Programmers are fallible; if tools can prevent
some common errors (even if it means doubling the computation time),
then those tools are worth using.

I'd rather not be the first one to finish, if my answer is wrong!

Duncan Murdoch


<HR><A NAME = "77veih$[e-mail]"></A>
Subject: Re: Random numbers for C: Improvements.
Date: 18 Jan 1999 08:56:33 -0500
From: [e-mail] (Herman Rubin)
Message-ID: &LT;77veih$[e-mail]>
References: <A HREF = "#[e-mail]">&LT;[e-mail]></A>
Newsgroups: sci.stat.math
Lines: 63

In article &LT;[e-mail]>,
Duncan Murdoch &LT;[e-mail]> wrote:
>On 17 Jan 1999 13:22:21 -0500, [e-mail] (Herman Rubin)
>wrote:
>>  But the procedure call overhead would be comparable
>>to the computing cost; 

>I don't know if that's true or not, but I don't think it is really
>something to worry about.  The uniform value coming out of these
>macros is unlikely to be the end of the computation; you'll almost
>certainly do far more costly things with it after it's generated.  So
>halving or doubling the speed of the generator won't have nearly so
>much impact on the overall calculation.

It certainly is.  The cost of one procedure call could far exceed
the cost of a uniform, or even many nonuniform, random variables.
If procedure calls have to be made in the generation, I would not
be surprised to have a factor of 10 or more.  BTW, I would not
use any pseudo-random procedure in a