[Insight-users] Missing use of ReinitializeSeed in MutualInfo. metric?

Karthik Krishnan Karthik.Krishnan at kitware.com
Sat Apr 30 20:30:15 EDT 2005


Hi Erik,

You may also include quasi-random initialization if you like as in

metric->ReinitializeSeed(vcl_ctime(0));
A default seed is supplied during the first call to drand by most 
compilers except the cygwin-gcc, which was why the function was added, 
so you could call it explicitly from your code. The metric constructor 
doesn't use it to ensure that testing is consitent.

The MersenneTwister was  added to ITK recently and is generally 1-6 
times faster than its vnl counterpart (except on the SGIs ?? ) and it 
exhibits more randomness too.

Thanks
regards
karthik






Erik Harg wrote:

> Hi,
>
> I have a question regarding the randomness (or, rather, the lack of 
> it) of the random number generator in 
> ImageRandomConstIteratorWithIndex, as used in the 
> MutualInformationImageToImageMetric.
>
> In my experience, with the same number of sample points, and the same 
> fixed/moving images, the Iterator always chooses the same sample 
> points, and the resulting MI metric values are always identical. This 
> is occurring both under Mac OS X and Linux, using itk versions from 
> 1.8 to 2.0.
>
> As far as I can tell, when the MutualInformationImageToImageMetric 
> calls the ++randIter, the increment operator of the 
> ImageConstIteratorWithIndex calls RandomJump(), which in turn uses 
> vnl_sample_uniform(). However, I have not been able to find any 
> preceding call to the reseed function of the iterator, nor directly to 
> the vnl_sample_reseed() functions. [1]
>
> In the almost 6 months I have been watching this list, some threads 
> related to this issue have emerged, but (I believe) not covering 
> exactly what I am thinking about...
>
> My question then, is this: Am I correct in noticing that the 
> MutualInformation Metric does not seed the random number generator, 
> and is there a good reason for it not to use its own 
> ReinitializeSeed() function (or the one in the Iterator)?
>
> I notice that in some of the RegistrationExamples included with the 
> itk source, there are specific calls to vnl_sample_reseed(int seed), 
> using seed=8775070 or 76926294. However, wouldn't it be a more general 
> approach to let the MI metric, or even the Iterator, handle the 
> seeding, to ensure that the correct function is called?
>
> There is probably a good answer to this, and I am looking forward to 
> hearing it! Thank you.
>
> Regards,
>
> Erik
>
>
> [1]
> Looking at the source code for the vnl (vnl_sample.cxx in the 
> Utilities/vxl/core/vnl directory of the itk source tree), it seems 
> that this function will either use the drand48() stdlib function if 
> available, or use a simple congruential random number generator. As 
> far as my understanding of (pseudo-)random number generators go, both 
> of these need a decent seed to provide anything close to random 
> numbers. The congruential generator that is built into the vnl has a 
> static seed of 12345, unless a call to vnl_sample_reseed() or 
> vnl_sample_reseed(int seed) precedes the vnl_sample_uniform() function 
> call. However, when vnl is using the drand48(), no default seeding 
> (using srand48()) is done, and I believe the last system provided seed 
> is used(?). Thus, any call to vnl_sample_uniform() should be preceded 
> by a call to vnl_sample_reseed() (which uses the vcl_time(0) as seed 
> to srand48()), or to vnl_sample_reseed(int seed) using some user 
> defined seed. Only this will ensure a basic pseudo-random behaviour of 
> the uniform random number generator, I believe.




More information about the Insight-users mailing list