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])Dmitriradford@cs.toronto.edu (Radford Neal) writes:> >George Marsaglia &LT;geo@stat.fsu.edu> 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;790f49x60.fsf@poole.statgen.ncsu.edu>,> Dmitri Zaykin &LT;zaykin@statgen.ncsu.edu> 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.<HR><A NAME = "36A21A2C.AD5145D1@concentric.net"></A>Subject: Re: Random numbers for C: Improvements.Date: 17 Jan 1999 08:06:29 PSTFrom: Ramin Sina &LT;rsina@concentric.net>Message-ID: &LT;36A21A2C.AD5145D1@concentric.net>References: <A HREF = "#7pv8f55tf.fsf@poole.statgen.ncsu.edu">&LT;7pv8f55tf.fsf@poole.statgen.ncsu.edu></A>Newsgroups: sci.math,sci.math.num-analysis,sci.stat.mathLines: 34Dmitri 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>> radford@cs.toronto.edu (Radford Neal) writes:>> > >George Marsaglia &LT;geo@stat.fsu.edu> 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 inpractice. I am lost in the discussion in this thread, but I would likevery much to understand how to use these for example to generate 1000uniform random numbers between betwen A and B ( say 5 and 10) .Thanks very much,Ramin Sina---------------------------------------------------------- Ramin Sina                         rsina@concentric.net<HR><A NAME = "77vrbs$pmj$1@sun500.nas.nasa.gov"></A>Subject: Re: Random numbers for C: Improvements.Date: 18 Jan 1999 17:34:52 GMTFrom: hook@nas.nasa.gov (Ed Hook)Message-ID: &LT;77vrbs$pmj$1@sun500.nas.nasa.gov>References: <A HREF = "#7pv8f55tf.fsf@poole.statgen.ncsu.edu">&LT;7pv8f55tf.fsf@poole.statgen.ncsu.edu></A>Newsgroups: sci.math,sci.math.num-analysis,sci.stat.mathLines: 25In article &LT;7pv8f55tf.fsf@poole.statgen.ncsu.edu>,               zaykin@statgen.ncsu.edu (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: hook@nas.nasa.gov          |         less for my employer<HR><A NAME = "78207l$1l8$1@due.unit.no"></A>Subject: Re: Random numbers for C: Improvements.Date: 19 Jan 1999 13:10:13 GMTFrom: orjanjo@math.ntnu.no (Orjan Johansen)Message-ID: &LT;78207l$1l8$1@due.unit.no>References: <A HREF = "#77vrbs$pmj$1@sun500.nas.nasa.gov">&LT;77vrbs$pmj$1@sun500.nas.nasa.gov></A>Newsgroups: sci.math,sci.math.num-analysis,sci.stat.mathLines: 21In article &LT;77vrbs$pmj$1@sun500.nas.nasa.gov>,Ed Hook &LT;hook@nas.nasa.gov> wrote:>In article &LT;7pv8f55tf.fsf@poole.statgen.ncsu.edu>,>               zaykin@statgen.ncsu.edu (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 ... isguaranteed to happen before the assignment.  As far as I understand,what is not guaranteed is that any assignments in ... would happenbefore the one to y.Greetings,豶jan.<HR><A NAME = "36a4cb5e.39101741@news.snafu.de"></A>Subject: Re: Random numbers for C: Improvements.Date: Tue, 19 Jan 1999 18:29:34 GMTFrom: horst.kraemer@snafu.de (Horst Kraemer)Message-ID: &LT;36a4cb5e.39101741@news.snafu.de>References: <A HREF = "#77vrbs$pmj$1@sun500.nas.nasa.gov">&LT;77vrbs$pmj$1@sun500.nas.nasa.gov></A>Newsgroups: sci.math,sci.math.num-analysis,sci.stat.mathLines: 39On 18 Jan 1999 17:34:52 GMT, hook@nas.nasa.gov (Ed Hook) wrote:> In article &LT;7pv8f55tf.fsf@poole.statgen.ncsu.edu>,>                zaykin@statgen.ncsu.edu (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 anlvalue.According to your theory	y = y - 1would produce undefined behaviour, too ....What produces undefined behaviour in C is _modifying_ an lvalue morethan once between the last and next sequence point. There is only onemodification of y in the expression	 t[c+237] = x-(y=t[c+1]+(x&LT;y))RegardsHorst<HR><A NAME = "77t9ot$15ha@b.stat.purdue.edu"></A>Subject: Re: Random numbers for C: Improvements.Date: 17 Jan 1999 13:22:21 -0500From: hrubin@b.stat.purdue.edu (Herman Rubin)Message-ID: &LT;77t9ot$15ha@b.stat.purdue.edu>References: <A HREF = "#99Jan15.151547edt.785@neuron.ai.toronto.edu">&LT;99Jan15.151547edt.785@neuron.ai.toronto.edu></A>Newsgroups: sci.math,sci.math.num-analysis,sci.stat.mathLines: 49In article &LT;99Jan15.151547edt.785@neuron.ai.toronto.edu>,Radford Neal &LT;radford@cs.toronto.edu> wrote:>>George Marsaglia &LT;geo@stat.fsu.edu> 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;790f49x60.fsf@poole.statgen.ncsu.edu>,>Dmitri Zaykin &LT;zaykin@statgen.ncsu.edu> 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 somemore detail.  But the procedure call overhead would be comparableto the computing cost; C, and all other languages, have such greatbuilt-in inefficiencies that what is needed is something writtenfrom the standpoint of mathematics and efficiency.  But even the use of a comparison is a costly operation, if theresult 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 propertiesof computers, and attempts to keep stupid people from makingmistakes.  An idiot-proof language is only for idiots.-- This address is for information only.  I do not claim that these viewsare those of the Statistics Department or of Purdue University.Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399hrubin@stat.purdue.edu         Phone: (765)494-6054   FAX: (765)494-0558<HR><A NAME = "36a23371.10418803@newshost.uwo.ca"></A>Subject: Re: Random numbers for C: Improvements.Date: Sun, 17 Jan 1999 19:10:01 GMTFrom: dmurdoch@pair.com (Duncan Murdoch)Message-ID: &LT;36a23371.10418803@newshost.uwo.ca>References: <A HREF = "#77t9ot$15ha@b.stat.purdue.edu">&LT;77t9ot$15ha@b.stat.purdue.edu></A>Newsgroups: sci.stat.mathLines: 27On 17 Jan 1999 13:22:21 -0500, hrubin@b.stat.purdue.edu (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 reallysomething to worry about.  The uniform value coming out of thesemacros is unlikely to be the end of the computation; you'll almostcertainly do far more costly things with it after it's generated.  Sohalving or doubling the speed of the generator won't have nearly somuch impact on the overall calculation.On the other hand, if it's programmed in a way that is sometimesincorrect in hard to detect ways, it might invalidate the wholecalculation.  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 occasionallapses of non-idiots.  Programmers are fallible; if tools can preventsome 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$11ts@b.stat.purdue.edu"></A>Subject: Re: Random numbers for C: Improvements.Date: 18 Jan 1999 08:56:33 -0500From: hrubin@b.stat.purdue.edu (Herman Rubin)Message-ID: &LT;77veih$11ts@b.stat.purdue.edu>References: <A HREF = "#36a23371.10418803@newshost.uwo.ca">&LT;36a23371.10418803@newshost.uwo.ca></A>Newsgroups: sci.stat.mathLines: 63In article &LT;36a23371.10418803@newshost.uwo.ca>,Duncan Murdoch &LT;dmurdoch@pair.com> wrote:>On 17 Jan 1999 13:22:21 -0500, hrubin@b.stat.purdue.edu (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 exceedthe cost of a uniform, or even many nonuniform, random variables.If procedure calls have to be made in the generation, I would notbe surprised to have a factor of 10 or more.  BTW, I would notuse any pseudo-random procedure in a