[java] Random numbers not random enough...

Well, you could try a pseudorandom number generator other than what you're using--I assume it's the C library's rand(). Another option is to keep a list of the last x values generated and make sure that any new value isn't already in the list. Eventually, the list will be filled and then you'll want to start purging it for each new value you add. Just a thought.

Edited by - merlin9x9 on April 20, 2001 6:04:11 AM

Thanks for you remarks I''ve sussed it!
BTW have you any thoughts on how I might implement a simple countdown clock from 60-0 sort of thing.
As you might have guessed I''m new to Java and am feeling my way a bit.

Thanks

Admittedly, I have no Java experience, so the only thing I can suggest sounds like an insult to your intelligence; this is purely unintentional. I assume that Java has a function to delay program execution for a certain amount of time. If so, just use that, of course. If not, I assume that Java has some function to get the current time. If so, you can have a loop to keep checking the time and decrement the counter only after the amount of time you want between ticks of your counter has elapsed.

Use the call System.currentTimeMillis() to get the current time, the value returned is measured in milliseconds and it should be accurate enough to do what you want to do! Long story....

Greetings ..

Here is a method to delay program execution:

try { Thread.sleep(1000); }catch(InterruptedException e) {}

This source will delay the program for 1 second. For two seconds the value passed to sleep() would be 2000, for a half a second it would be 500 and so forth.

Cheers, JP.

==============================================
I feel like a kid in some kind of store...
==============================================
www.thejpsystem.com

The value returned by System.currentTimeMillis() is accurate down to a resoulution of 1 millisecond, but the JRE implementation for Windows only updates the value returned 17(ish.. I can''t remember the exact number) times a second, this isn''t a problem unless you need to do some accurate timing, but anything on the scale of 1 second is fine. This call can be used for games if used alongside some other mechanisms, I''ve got a method in place which returns times accurate to milliseconds even on Windows machines and doesn''t suffer from the problems of currentTimeMillis(), as long as the frame rate stays constant it works brilliantly. (and it ain''t native code.)

I would advise against using the method put forward by loserkid, if you only want it to be roughly 1 second then it''s fine, but anything lower than 1/10th of a second and you might hit problems, it isn''t guaranteed that it''s going to be bang-on 1 second, but on that kind of timescale you''re not going to notice the difference. The actual time that the thread will sleep for can vary quite dramatically depending on processor usage, and just because you''re not using it doesn''t mean that nothing else will be.

JJ.

I think what the original poster was doing is creating a new Random object for each call of his "getBlock. Java''s Random object uses the current system time as the seed.
This means that he will probably seed it with the same time serveral times in a row and get a not so random distribution of blocks. I.e. the calls will be that quick that time will not have moved on.

The solution (well one) is to create a Random object then call the same one to get each sequential random number.
As long as you don''t re-seed this Random you should get the proper distribution of psuedo random numbers..
which is going to be random enough for this type of thing.

Hammer

That could definitely explain what is going on, especially when taken in to account with the problem with currentTimeMillis().

But if he''s using Math.random() then that won''t be the problem, the first time you make this call it will create a Random object(using the current time as the seed) and use this same object for each subsequent call, which is effectively the same as Hammer''s solution.

JJ.