KISS4691, a potentially top-ranked RNG.
in [Fortran]
|
Prev: solutions book
Next: real kind declaration
From: robin on 6 Aug 2010 06:11 "Uno" <merrilljensen(a)q.com> wrote in message news:8c0nh6FkkvU1(a)mid.individual.net... | I'll restate the question, and I'm sure you'll get my drift. When I | compile off a command line, I keep the command lines I used as the final | comments in that file. So there might, in fortran, exist | | implicit real | pi = 4.0 * atan(1.0) | print *, pi | endprogram | | !here it comes, the goocher: | | ! gfortran pi1.f90 -o out | | 1) What did you name this pli thing? RNG-2010.PLI | 2) What command compiled it? PL/I RNG-2010 | 3) How does one comment in pli? /* Stuff */
From: mecej4 on 9 Aug 2010 10:52 Uno wrote: > robin wrote: >> "James Waldby" <no(a)no.no> wrote in message >> news:i39iqp$sg7$1(a)news.eternal-september.org... >> | On Tue, 03 Aug 2010 20:41:15 +1000, robin wrote: >> | > "Uno" <merrilljensen> wrote: >> | [snip code] >> | >> If you were to comment out the PL/I command line that compiled this, >> | >> what would it be? >> | > >> | > ??? >> | >> | Does that mean you don't understand Uno's question, >> | or don't know the answer? >> >> It means that the question makes no sense. >> >> > Does this make sense? > > I'll restate the question, and I'm sure you'll get my drift. When I > compile off a command line, I keep the command lines I used as the final > comments in that file. So there might, in fortran, exist > > implicit real > pi = 4.0 * atan(1.0) > print *, pi > endprogram > > !here it comes, the goocher: > > ! gfortran pi1.f90 -o out > > 1) What did you name this pli thing? > > 2) What command compiled it? > > 3) How does one comment in pli? > > 4) How does one acquire a pli facilty on ubuntu? Those kinds of basic questions are mostly covered by the PL/I FAQ, which is posted quite regularly in this newsgroup. As far as I am aware, there is no production quality native PL/I compiler available for Linux. There is VisualAge PL/I for Windows, which IBM makes available through its Scholars Program to those who qualify or which may be purchased (at significant cost) as part of the Rational Developer for System Z product. -- mecej4
From: Gib Bogle on 10 Aug 2010 14:02 orz wrote: > On Jul 30, 10:14 pm, Gib Bogle <g.bo...(a)auckland.no.spam.ac.nz> wrote: >> orz wrote: >>> Yes. Sorry. I was reading backwards from your last post and ended up >>> missing the point. And getting confused on the sign. >>> Anyway, the issue is that Georges code uses a different definition of >>> sign than your implementation of it - his code is actually correct if >>> sign(x) is 1 if x is positive and 0 if x is negative. Since your sign >>> function returns -1 on negative, using it produces the wrong >>> results. >>> side note: The incorrect results produced that way at a appear to have >>> vaguely similar statistical properties as the original C codes output, >>> passing and failing the same tests that the original C code does in my >>> brief tests. >> Interesting, who would have guessed that there is a language in which sign(-1) = 0. > > I have to correct myself for swapping 0 and 1 *again*. And I'm not > even dyslexic, so far as I know. > > His code assumed sign returned 1 on negative, and 0 otherwise, as in a > simple unsigned 31 bit rightshift. The exact opposite of what I > said. I tried your suggestion, replacing the sign() function with one based on your rule. It doesn't work, i.e. it gives results different from the C code.
From: orz on 10 Aug 2010 15:32 On Aug 10, 11:02 am, Gib Bogle <g.bo...(a)auckland.no.spam.ac.nz> wrote: > orz wrote: > > On Jul 30, 10:14 pm, Gib Bogle <g.bo...(a)auckland.no.spam.ac.nz> wrote: > >> orz wrote: > >>> Yes. Sorry. I was reading backwards from your last post and ended up > >>> missing the point. And getting confused on the sign. > >>> Anyway, the issue is that Georges code uses a different definition of > >>> sign than your implementation of it - his code is actually correct if > >>> sign(x) is 1 if x is positive and 0 if x is negative. Since your sign > >>> function returns -1 on negative, using it produces the wrong > >>> results. > >>> side note: The incorrect results produced that way at a appear to have > >>> vaguely similar statistical properties as the original C codes output, > >>> passing and failing the same tests that the original C code does in my > >>> brief tests. > >> Interesting, who would have guessed that there is a language in which sign(-1) = 0. > > > I have to correct myself for swapping 0 and 1 *again*. And I'm not > > even dyslexic, so far as I know. > > > His code assumed sign returned 1 on negative, and 0 otherwise, as in a > > simple unsigned 31 bit rightshift. The exact opposite of what I > > said. > > I tried your suggestion, replacing the sign() function with one based on your > rule. It doesn't work, i.e. it gives results different from the C code.. If I made yet another mistake on that then I'm going to throw something. It produced identical results for me when I tried it in C using this code: typedef unsigned int Uint32; Uint32 sign(Uint32 value) {return value>>31;} Uint32 index, carry, data[4691]; Uint32 mwc4691() { index = (index < 4690) ? index + 1 : 0; Uint32 x = data[index]; Uint32 t = (x << 13) + carry + x; if (sign((x<<13)+carry) == sign(x)) carry = sign(x) + (x>>19); else carry = 1 - sign(t) + (x>>19); data[index] = t; return t; } I think the only difference between that and the algorithm he expressed in pseudocode is that I added parentheses on the first left- shift (he was apparently assuming higher precedence on the leftshift operator than C uses). Maybe that's why you're getting different results?
From: Gib Bogle on 10 Aug 2010 20:54
orz wrote: > If I made yet another mistake on that then I'm going to throw > something. > > It produced identical results for me when I tried it in C using this > code: > > typedef unsigned int Uint32; > Uint32 sign(Uint32 value) {return value>>31;} > Uint32 index, carry, data[4691]; > Uint32 mwc4691() { > index = (index < 4690) ? index + 1 : 0; > Uint32 x = data[index]; > Uint32 t = (x << 13) + carry + x; > if (sign((x<<13)+carry) == sign(x)) > carry = sign(x) + (x>>19); > else carry = 1 - sign(t) + (x>>19); > data[index] = t; > return t; > } > > I think the only difference between that and the algorithm he > expressed in pseudocode is that I added parentheses on the first left- > shift (he was apparently assuming higher precedence on the leftshift > operator than C uses). Maybe that's why you're getting different > results? You do realize that there's no unsigned integer type in Fortran? I don't think there's much point in trying to predict what the Fortran code does without using a Fortran compiler. Don't you have one? |