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

[Erik Harg]

On Sat, 30 Apr 2005, Luis Ibanez wrote:

> Hi Erik,
>
> Thanks for pointing this out.
>
> You are right,
> we should invoke the ReinitializeSeed() method
> as described in the Doxygen documentation,
> [...]
> instead of having explicit calls to vnl_sample_reseed().
>
Thanks for your clear reply, Luis.

Replacing the explicit vnl function calls with the more encapsulated 
ReinitializeSeed in the examples was part of my initial wondering.

> Note that most of the calls to vnl_sample_reseed() are
> actually in the test drivers, and not in the examples
> themselves. At that level, there are not metrics declared,
> so the only access to reinitialization is through a direct
> call to vnl_sample_reseed().
>
> The reason for doing the reseeding there is that we need
> to have repeateable behavior for the tests that are
> including in the nightly and continuous regression testing
> in the Dashboard.
>
As I wrote in the email to Karthik as well, I hadn't thought about ITK's 
test suite, and its need for a consistent and deterministic behaviour of 
the methods. So, reseeding with fixed values in the tests makes perfect 
sense.

> However,
> it will be clearer if we put the ReinitializeSeed()
> call directly in the examples that need it.
>
Then we agree on that. However, as I also asked Karthik about, I'm still 
wondering why the metric shouldn't, by default, initialize the random 
number generator using a quasi-random/time-based seed? A call to

this->ReinitializeSeed()

in the MutualInformationImageToImageMetric constructor (and other metrics 
that implements the method), would make the use of the random number 
generator more transparent to the average user. Users that wish to reseed 
the random number generator with a fixed seed, such as in the regression 
test classes, would still be able to do that through the ReinitializeSeed( 
int seed ) method, or directly through the underlying vnl_sample_reseed( 
int seed ). Please do enlighten me further, as there are likely to be 
other aspects I haven't thought of here!

Thanks again, Luis.

Regards,
Erik

> --------------------
> 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.
>
>
>
> _______________________________________________
> Insight-users mailing list
> Insight-users at itk.org
> http://www.itk.org/mailman/listinfo/insight-users
>

-- 
       *----------------------------------------------------------*
       | Erik Harg         924 98 541       Erik.Harg at idi.ntnu.no |
       |                NTNU - Trondheim                          |
       *----------------------------------------------------------*