eVC3 - No Device Installed?

[mlepage]

OK, regarding the RAND_INT macro...

I was aware that it could fail under extreme circumstances, both when a strange argument (e.g. 4+4) is used, and when RAND_MAX is returned.

Regarding the first case, it's true that you need to protect arguments and understand how macros evaluate arguments. I didn't here, because I only used the macro here to switch between the built-in random number generator and my own, for debugging this problem.

Regarding the second case, that formula is only used with the built-in random number generator; my own protects against that case. It's all in Stroustrup3e section 22.7. (If you wade through his later code, you'll see it's linear congruential, and it protects against that case.)

Stroustrup gives that formula as yielding adequate results under most circumstances, and my bug isn't that I'm suddenly hitting RAND_MAX within a few calls to rand(). (Consider, if so, why it wouldn't happen in debug builds?) I wonder if Stroustrup may address that failing of that formula in later printings (I have the first printing, I was keenly awaiting that book).

BTW you don't want to simply add 1 to your max compenstate for that failing because that will throw off your uniform random distribution.

The traditional reason for using a formula such as this, and not modulus, is that with linear congruential sequences (which is what rand uses to generate pseudorandom numbers) have not-as-random lower bits (which is what modulus uses). For more info, web search for the online copy of Numerical Recipes in C Second Edition, there is a chapter on random number generation that's very interesting (to nerds like us).

So you are both right, but I am aware of these issues and they exist only in this code for reproducing the problem.

For a limited time, you can get a copy of the project here: http://www.scalenesoftware.com/Minimal- ... -Error.zip

[mlepage]

OK regarding the bit-and trick, I see exactly what it's doing, it's just a modulus because it's a power of 2 and we are using binary.

In this project, I only use a few random numbers now and then, so performance isn't an issue. But I'll switch nextCol to it anyways.

[Dan East]

Assuming RAND_MAX is always 0x7fff, then try this:

#define RAND_INT(max) ((rand() * (max))>>15)

It can still return 0 <= n <= max, but at least it is all integer math and maintains your linearitarian stuff. max has to be <= 65535

Dan East

[mlepage]

RAND_INT doesn't exist in my code, I use my own random number generator. It uses the same basic floating-point method, but protects against the case where RAND_MAX is returned.

I only had RAND_INT to switch to the built-in random number generator to debug this problem. BTW switching random number generators had no effect on the optimzer error.

I am not worried about random number generation performance, I use them extremely rarely. At present, I generate about 6 random numbers every 6 seconds or so. If my XScale can't cope with that I'm throwing it in the diaper pail. :-)

[sponge]

You expect a processor to come up with one random number a second? Problem solved, hire me, and I'll yell out numbers for you.

[denthorq]

[Kak]

[mlepage]