KISS4691, a potentially top-ranked RNG.
in [Fortran]
|
Prev: solutions book
Next: real kind declaration
From: Gib Bogle on 30 Jul 2010 22:00 orz wrote: > I think you have part of it backwards: > elseif (x < 0) then > tLTx = 1 > elseif (t < 0) then > tLTx = 0 > endif > > should be: > elseif (x < 0) then > tLTx = 0 > elseif (t < 0) then > tLTx = 1 > endif > > ...if you want to produce an sequence of numbers identical to his C > code. Though the way you have it written produces significantly > higher quality output according to some statistical tests. > > Another issue to worry about is the rightshift must be an unsigned > rightshift, but a quick googling suggests that fortran ISHFT is > unsigned anyway. I think you are wrong. The code as I have it is correct, as far as I'm concerned, and it produces identical results to the C code, when the signed values are treated as unsigned (or vice versa). Remember, a signed negative (e.g. x < 0) is representing an unsigned value greater than 2^31 - 1. In the conditional code you refer to, signed x < 0 and signed t > 0 => unsigned x >= 2^31 and unsigned t < 2^31. Q.E.D. As Glen pointed out, this all assumes a two's complement number representation, such as is used by my Intel CPU/Intel compiler combination.
From: orz on 30 Jul 2010 22:34 On Jul 30, 7:00 pm, Gib Bogle <g.bo...(a)auckland.no.spam.ac.nz> wrote: > orz wrote: > > I think you have part of it backwards: > > elseif (x < 0) then > > tLTx = 1 > > elseif (t < 0) then > > tLTx = 0 > > endif > > > should be: > > elseif (x < 0) then > > tLTx = 0 > > elseif (t < 0) then > > tLTx = 1 > > endif > > > ...if you want to produce an sequence of numbers identical to his C > > code. Though the way you have it written produces significantly > > higher quality output according to some statistical tests. > > > Another issue to worry about is the rightshift must be an unsigned > > rightshift, but a quick googling suggests that fortran ISHFT is > > unsigned anyway. > > I think you are wrong. The code as I have it is correct, as far as I'm > concerned, and it produces identical results to the C code, when the signed > values are treated as unsigned (or vice versa). Remember, a signed negative > (e.g. x < 0) is representing an unsigned value greater than 2^31 - 1. In the > conditional code you refer to, signed x < 0 and signed t > 0 => unsigned x >= > 2^31 and unsigned t < 2^31. Q.E.D. > > As Glen pointed out, this all assumes a two's complement number representation, > such as is used by my Intel CPU/Intel compiler combination. Whoops, you are correct, I somehow got the two mixed up even when testing them in code. But in that case I don't know what you meant in your previous post when you asked about differences between your output and the original output. If the information produced is identical, then the information produced is identical.
From: Gib Bogle on 30 Jul 2010 23:04 orz wrote: > Whoops, you are correct, I somehow got the two mixed up even when > testing them in code. > > But in that case I don't know what you meant in your previous post > when you asked about differences between your output and the original > output. If the information produced is identical, then the > information produced is identical. Please look at the code. You'll see that tLTx is used only to compute c_this_works. The code as I posted it contains the method of computing c suggested by George. This generates results different from the C code. If you uncomment the line c = c_this_works you get identical results to the C code. I'm sure I already said this.
From: orz on 31 Jul 2010 00:24 On Jul 30, 8:04 pm, Gib Bogle <g.bo...(a)auckland.no.spam.ac.nz> wrote: > orz wrote: > > Whoops, you are correct, I somehow got the two mixed up even when > > testing them in code. > > > But in that case I don't know what you meant in your previous post > > when you asked about differences between your output and the original > > output. If the information produced is identical, then the > > information produced is identical. > > Please look at the code. You'll see that tLTx is used only to compute > c_this_works. The code as I posted it contains the method of computing c > suggested by George. This generates results different from the C code. If you > uncomment the line c = c_this_works you get identical results to the C code. > I'm sure I already said this. 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.
From: Gib Bogle on 31 Jul 2010 01:14
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. |