I wrote:
Since the latter is typical of the non-integral results
that we see for 30269*30307*30323*RAND(), I suspect that
RAND() uses type Single for intermediate computations
internally(!).

That may or may not be true (probably not), but RAND() certainly is not
implemented like my sngRAND().

If it were, the binary pattern of the RAND() result would look something
like &h3FEB1B11,C0000000. That is, the mantissa would end in at least 29
zero bits.

Instead, the RAND() result typically looks like &h3FE13AF7,E7F36098,
utilizing the full 53 bits of the type Double precision.


----- original message ------

"Joe User" joeu2004 wrote in message
...
"Hans Terkelsen" dk wrote:
However the RAND() article gives an overview only, I think.

I do not think so. I have found many similar explanations of the
Wichman-Hill(1982) algorithm. Most are similar to KB 828795 in effect, if
not exactly the same. (Caveat: Some are obviously wrong in some details,
notably the wiki explanation.)


If that was the full story then
=30269*30307*30323*RAND() should be close to an
integer, which it is not.

Thanks for that insight. You might have stumbled onto the key reason why
it has been difficult to infer the 3 internal factors given a RAND()
result. (Well, it is still difficult. But I mean: why I always had
infinitesimal differences when I tried to apply the inferred factors.)

Consider the following two implementations of the Wichman-Hill(1982)
method of computing the random value, given the 3 internal factors.

Function sngRAND(ix As Single, iy As Single, iz As Single) As Single
ix = ix / 30269! + iy / 30307! + iz / 30323!
sngRAND = ix - Int(ix)
End Function

Function dblRAND(ix As Double, iy As Double, iz As Double) As Double
ix = ix / 30269# + iy / 30307# + iz / 30323#
dblRAND = ix - Int(ix)
End Function

You are correct that 30269*30307*30323*dblRand() is "always" close to an
integer, for random values of IX=1,...,30268, IY=1,...,30306 and
IZ=1,30322. (At least for the many random values that I tried.)

But for the same values of IX, IY and IZ, 30269*30307*30323*sngRand() is
often not close to an integer.

For example, for IX=23695, IY=9539 and IZ=3705,
30269*30307*30323*dblRand() is about 6112669340694.00, but
30269*30307*30323*sngRand() is about 6112668665232.35.

Since the latter is typical of the non-integral results that we see for
30269*30307*30323*RAND(), I suspect that RAND() uses type Single for
intermediate computations internally(!).

And there might also be other internal computational factors that could
contribute to the unexpected results.


----- original message -----

"Hans Terkelsen" dk wrote in message
...

"Joe User" joeu2004 wrote in message
...
"Joe User" joeu2004 wrote:
...
I was able to learn some details about VB Rnd because it does produce a
repeatable sequence unless you call Randomize. But what I learned was
made possible only because the default seed is documented in KB 231847.

Since KB 828795 fails to document the default seed (I suspect now there
is none), it does not help to disable the initial seeding. I am still
stuck with trying to infer the 3 factors in the Wichman-Hill algorithm,
ass-u-me-ing that KB 828795 is correct. I had developed an inferential
algorithm in Dec'09. And for that, any RAND result will do; I do not
even need a sequence.

I was never entirely satisfied with the results of the inferential
approach because it was always off in some low-order binary bits. The
difference was small enough to be "close enough for government work",
but too large to be explained by some nuance of computer arithmetic.

I was hoping that I now had a new approach to try. But I am wrong.

...
Hi Joe.

I have tried some of the same things, that you have.
Just out of curiosity.

The VBA Rnd article gives the full story, it is easy to reconstruct Rnd
in the worksheet.

However the RAND() article gives an overview only, I think.
If that was the full story then
=30269*30307*30323*RAND() should be close to an integer, which it is not.
I could not locate more info, so I gave up!

Good luck Hans T.