search

davidwhogg / LensTractor

finding strong gravitationally lensed quasars in ground-based data
GNU General Public License v2.0
5 stars 4 forks source link

Sampling is not operational #21

Closed drphilmarshall closed 10 years ago

drphilmarshall commented 10 years ago

I will fix this. Emcee used to work, albeit slowly. Experimental idea is to emcee a few steps and then optimize from the highest likelihood one, in order to solve the initialization of a non-linear optimization problem... Comments welcome.

dstndstn commented 10 years ago

tractor.optimize() does a single step of linearized least squares. Running for many steps allows it to work its way through a non-linear space. Emcee is not a very effective optimizer. Imagine that you start in a bad part of parameter space and one walkers finds a much better place. It can take many steps before the rest of the walkers select the good one as their partner and step in the right direction, finding that good place. I would like to develop a modification of emcee -- Trogdor, the burn-in-ator, to make smarter decisions when using sampling for optimization. But until that happens, you might find that it works better to run (maybe a few parallel) Metropolis-Hastings samplers, rather than an emcee ball.

drphilmarshall commented 10 years ago

Hmm, I see. One possibility could be to manually offset the ball to the best walker position every few samples. The goal here is not really to use emcee as an optimizer, but instead robustly find a good starting place for the optimizer. Sampling is now operational again, and easily called via the LensTractor.driver, so that @aagnello can experiment a bit. I'll close this issue, but feel free to carry on suggesting possible algorithms for achieving sensible fits in finite runtimes using the two available methods at our disposal! ;-)

davidwhogg commented 10 years ago

Yes, you are permitted to hack away for initialization. Not for the final sampling, of course