From: Ian S. <ian...@st...> - 2005-03-09 16:39:33
|
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. |
From: Luis I. <lui...@ki...> - 2005-03-11 04:50:09
|
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? > > > > > |
From: Luis I. <lui...@ki...> - 2005-03-11 04:03:24
|
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. > > |