The VXL Project

Hi Ian,

Thanks for your interest in this issue.

Please note that we already took the work-around suggested by
Andrew Fitzgibbon in order to maintain const-correctness in
the ITK cost_functions and optimizers despite the lack of
const-correctness in the VNL ones. So, at this point, you could
simply ignore my original request.

I must admit that this is quite a selfish attitude on my part,
but const-correctness battles tend to be long ones and there is
no longer motivation for fighting this one, specially considering
that even if we fix today the code in VNL, it would take between
six months and one year for these changes to propagate into the
ITK release, given that we update VNL at most once a year, and
that we do ITK releases every six months.



However,
just for the sake of clarifying the motivation
for the original request:


The problem with the optimizers and cost-functions API in VNL is
visible by applying the algorithm that is used when deciding for
the constness of methods in a class:


      IF(  Should this invocation change the class ?  )
        {
        THEN the method is "non-const"
        }
      ELSE
        {
        THEN the method is "const"
        }


 From this criterion: an optimizer should manage cost-functions as
"const" objects. This is not the case now in VNL, where the optimizer
can in fact modify a cost-function class.  Thanks to this first gap,
you are not affected by the fact that cost-functions have evaluation
methods that are non-const. This is a typical case of a double gap in
const-correctness that allows the non-constness to pass unnoticed.

Again, I agree with you and Andrew in that "there is a way" to use the
current VNL API from const-correct external optimizers and external
cost functions. This however, simply means that there is a way to get
around the real problem, it doesn't mean that the problem doesn't exist.


I think we agree on the basic fact that cost-functions are not supposed
to change when they are evaluated. The only case when changes occur in
the class is when they cache data, and in that case, the cached
variables must be declared "mutable", because that indicates that
they are transient data that do not represent the "state" of the
object. For example, mutable variables must not be used when serializing
an object for the purpose of saving it into a file or sending it
through the network.


When we perform Image Registration in ITK by passing an Image Metric to
an optimizer, we don't want that optimizer to change the Metric's state
in any way. That is our motivation for being so zealous on the 
const-correctness of ITK optimizers and cost-functions.



--



We appreciate your rapid response to our annoying request and apologize
for making so much fuss on an issue that, even if we solve it, will not
have any immediate impact or benefit to the VXL community.




    Best regards,



        Luis




--------------------
Ian Scott wrote:

> Luis Ibanez wrote:
> 
>>
>> Dear vnl-users:
>>
>>
>> We have been using the VNL optimizer in the Insight Toolkit (ITK)
>> by wrapping them into thin ITK classes.
>>
>>
>> This is the case for classes such as:
>>
>>    Amoeba
>>    Levenberg-Marquardt
>>    Conjugate gradient descent
>>
>>
>> We recently found a problem with the definition of const-correctness
>> in the vnl_cost_function that is propagating into ITK and preventing
>> us from implementing constness... correctly      :-)
>>
>>
> 
> 
> 
> My own experience of using the optimiser is with complicated cost 
> functions that did a fair bit of caching - even between multiple calls 
> to the optimiser.
> 
> I guess I could rewrite my code to store the cache as mutable. But I'm 
> afraid at present that I don't entire understand your problem. At least 
> once, I used the optimisers inside a const method without a problem - 
> although the cost function wasn't a member variable obviously. Could you 
> be a bit more explict about your const-propagation problem.
> 
> 
>  > We have noticed that VXL does in general a pretty good job of supporting
>  > const-correctness. This make us think that you should have had good
>  > reasons for leaving some of the cost-function methods to be non-const.
>  > We will appreciate your insights on the rational behind the choices
>  > you made for assigning const/non-const in the hierarchy of the cost
>  > functions.
>  >
>  >
>  > In general we will prefer not to have to modify our local copy of VNL
>  > since that will result in a huge effort the next time we update VNL
>  > in the ITK repository. It will be great if we can reach some consensus
>  > on the best way of customizing these classes.
> 
> If you can show that the existing API is actually wrong - I'm all for 
> fixing the code in the VXL repository.
> 
> 
> Thanks,
> Ian.
> 
> PS. I have moved this discussion from vxl-users to vxl-maintainers.
> 
>

Andrew,

Thanks for your rapid answer.

I agree with your statement regarding the possiblity of
using non-const cost_function methods inside the const
method of a different class.

Following your example I have modified the VNL CostFunction
Adaptors in ITK in such a way that they will provide safe
const-correctness face to ITK Optimizers and still use the
non-const calls of internal vnl_cost_functions.

The ITK wrappers around VNL optimizers have been modified
accordingly.


    Regards,


       Luis



--------------------------
Andrew Fitzgibbon wrote:

> Quick answer: those were designed pretty early, and predated widespread
> "mutable" support.
> 
> Other answer: I'm surprosed you ever find yourself with an optimizer
> object whose constness propagates.  If I want to fit an "Ellipse" to 
> "Data", there are a variety of cost functions I might implement.  One
> might be called "Sampson", and would be implemented thus:
> 
> struct Sampson: public vnl_cost_function {
>   const Data* thedata;
>   CachedStuff thestuff;
> 
>   double f(vnl_vector<double> const& x) {
>     Ellipse e(x);
>     double tot(0);
>     for k = 0 to data->n
>       tot +=  e.distance(data->point[k]);
>     cachedstuff.tot = tot;
>     return tot;
>   }
> };
> 
> 
> Then it might be used in a const method on Data:
> 
> Ellipse Data::fitellipse() const
> {
>    Sampson costfn;
>    costfn.data = this;
>    return Ellipse(amoeba(costfn));
> }
> 
> 
> I cannot see where constness will propagate, unless you try to
> multiply inherit Sampson from cost_function and Data, but why would
> one do that?
> 
> 
> 
> 
>