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

[Luis Ibanez]

Hi Erik,

The reason why we cannot put the quasi-random initialization
of the seed directly in the constructor of the Metric is that
it will then be impossible to have repeatable experiments for
the testing suite and for people who perform registration in
a systematic way.

There a applications that require repeatability, e.g. running
your program a second time, you want to get *exactly* the same
result. There are other applications that do not need or do not
want such a property.

The initialization of the seed cannot be enforced in the constructor
because some applications need it and some others don't. It is then
up to the application developer to make the decision on whether the
seed must be initialized or not.

We agree in that we must include a more detailed discussion of this 
issue in the next edition of the ITK Software Guide.


   Thanks for pointing this out,


      Luis


--------------------
Erik Harg wrote:
> 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
>>
>