[Insight-users] Why itk::LBFGSBOptimizer and itk::LBFGSOptimizer are classed as single-variant o

[Brad King]

Ali - wrote:
> Thanks for pointing out where the 'implementation problem :)' is
> located. I'll try to extend the optimiser for a multi0variant version.
> 
> Since both ITK and VNL implementation are only wrappers, it should be
> starightforward to implement this. However, since the access to lbfgs is
> through VNL, it makes sense to implement both wrappers. The complexity
> starts where we need to extend some part of VNL: assume at some point
> VNL developers provide a featue like this, in this case (1) our
> implementation in VNL is redundant, and (2) the ITK wrapper should point
> to the official implementation. I am not sure what would be the best
> policy to choose.

It looks from the rest of this thread that you may not be doing any
implementation, but if you do, here is the situation with VNL v. ITK.

The vnl inside ITK is just a snapshot of upstream vnl with the library
names changed to have an itk prefix.  Every year or two we update to the
latest vnl from upstream vxl.  We have close ties to the vxl developers,
and I have write access to vxl's CVS repository.  I have a CVS watch on
ITK's vxl directory so that whenever a fix is committed I am notified
and can port it over to vxl upstream.  Within a few weeks we will
probably be updating ITK's vnl again.  Now there is a vnl_lbfgsb which
can be used to remove the lbfgsb.c currently found in ITK and wrapped up
with LBFGSBOptimizer.

If you are going to add any features please go get an upstream vxl
checkout and add it directly to vnl.  You can post a patch to their
mailing list, or send it to me.  Their project page is

http://vxl.sourceforge.net/

After any feature is added to vnl in vxl upstream I can port it over to
ITK's vnl.

Thanks,
-Brad