Re: Simple optimization


"Bob Cummings" <rancho@xxxxxxxx> wrote in message
news:tY-dnfYp1qUgucPZnZ2dnUVZ_uqdnZ2d@xxxxxxxxxxxxxxx
Göran Andersson wrote:


Again my ignorance is showing here. I think you are suggesting in the
beginning of the program to generate say 10,000 random numbers and put
them in an array. Then as the program progresses just grab the next
number in the array. When I run out then fill the array again?


I think that Nick was thinking more in the line of creating the array
once, and use it over and over again. If you just refill the array after
using it once, there is no performance gain. On the contrary it uses more
operations and more memory to do the same thing.

There is a risk with reusing random numbers, though. If the size of the
array is too small so that you reuse the same numbers many times, you
might begin to see patterns in the simulation.

That would not do at all. I thought he was suggesting to just initiate the
generator once, make as many numbers as needed, then get rid of it. And
that would be more efficient then asking the generator to make a number on
demand as needed through out the simulation.

Why wouldn't it do?

Given a reasonably large set and a reasonably complicated simulation to
eliminate any chance of repetition I expect that this will work just fine.

People get too hung up on the word "random". There is no such thing
available - only approximations. You are saying that this is not a good
enough approximation but without actually saying what your requirements are.

The only true random number generators that I know of require dedicated
hardware to measure random noise in a physical circuit and even then a true
random number generator is rarely desirable on it own because, perversely,
it is not gauranteed to generate a "random" sequence of numbers.

In the old days before cheap computers people got by perftectly well using
tables of random numbers. The advantage then and now is that you can check
that they actually meet the distribution that you require (Incidentally your
simulation should probably be using different probability distributions in
certain areas - the real world doesn't go in for normal distributions as
much as programmers would like).


I can see how that would work especially since between each year time
period there are maintenance issues such as witting output files and
loading the next years maps. I am not very versed in using multi
threads and call backs but this might be a case for that?


As the task in itself doesn't need multi threading to work, using it
would only add complexity and overhead.

OK I am clueless about threading except for some examples in school work.
I just thought if I started a worker thread to generate the numbers,
another to write the files, and another to load up the new years data; it
might have been better then doing one thing, then the next and so forth.
I really need to grasp a better understanding threads and what they would
be good for.


That also has to do with patterns. A simple integer random generator has
a simple and predictable algorithm. If you use the lower bits of the
value you will se reaccuring series of numbers.


Ok I did encountered that problem in the past on another simulation. I
think I ended up using another number generator.

For a "simple" integer generator Random()&0x01 generates
10101010101010101... which is unlikely to be useful. The general rule is to
use bits from the middle.

If you have a good table of random numbers and you don't need many choices
you can effectively increase the size by looking at different bits - eg. a
table of 100 random 32 bit integers can be viewed as 3200 random binary
choices.



.