nfaggian
commented
12 years ago Hi Riaan,
I agree at the moment we are a bit locked into the sum of squared error metric and it would be a good idea to provide a few different optimization methods. I don't think its a good idea to make the top level register package too much more general, acually when I first started this is what I had in mind.
What I think we should do is perhaps change the way that the register module is put together. At the moment we explicitly select the optimization algorithm, for example:
from register import register
A = register.Register(...) B = register.KybicRegister(...) C = register.FeatureRegister(...)
I like this explicit selection of solvers, note that Kybic is a modified version of gradient descent so it inherits from Register, but FeatureRegister is a totally redefined class. These classes should probably be renamed to reflect the algorithms they implement:
A = register.LM(...) B = register.Kybic(...) C = register.Direct(...)
Then we could just introduce more registration algorithms by extending the register module - adding new classes to the register module (with tests).
Let me know how you go. Basically I just suggest adding a new registration class following a similar pattern to FeatureRegister. This pattern could look a lot like the Register class with a newly defined register method that wraps a better optimization algorithm.
It might make sense to have a base registration algorithm pattern that all these approaches could inherit from but lets just start with a new and tested class.
-N
riaanvddool
I have come to the unsettling conclusion that our api is somewhat flawed after chatting to a colleague about it.
While attempting to add a new metric (ticket_0024) I realized that the way metric is defined, and register.py works, we are assuming CG optimization with minimization of sum of squared error.
A different metric might require a completely new implementation or the Register class.
What would the api be like to allow a choice of metric AND optimizer?