-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
automatic wrappers for grid search and grid search with optimization #15
Comments
Not sure I fully follow the problem here. If we aren't grid-searching/optimising some parameters, they wouldn't be in the This would be the same way numpyro works, you don't have to specify what is fixed you only specify what is sampled over, everything else is treated as static and its value is used by the model object implicitly. |
An automatic grid search with optimization is now implemented, for cartesian grids. I want to suggest that a model object has an attribute which lists which parameters are considered as coordinates to be mapped over in grid searches, because they may have many other parameters to be inferred but which are not in general going to require grid searches (and which would scale badly at high dimension). I suggest a syntax we just do self.coords = ['dra', 'ddec'] # ['sep', 'pa'], or disk spatial params, etc The other parameters, frozen at grid search time, would be in I also suggest that we have a helper attribute |
I'm not really convinced of this, or maybe I don't really understand where things are happening. Where is this inference of the other parameters happening? Are these other parameters being inferred inside this grid search function? If not I can't see why they should live in the I am in general not a fan of having leaves within a class that are used to refer to other leaves within the class, I've not really found a situation where that is warranted, but again, I don't have the context to be able to provide any concrete examples of where this might be troublesome. You could hold the Parametric getter method for contrast 👍 Parametric setter method for contrast 👎 The getter methods are totally fine and just make working with classes easier. However, if you create a setter method that completely breaks with how everything else is done. That one (faux) leaf requires its whole own setter method, that you then won't be able to update using zodiax methods. This is a fundamental limit because I think you could mayyyybe get this behavior by taking a similar approach to |
Oh and looking at #20, I think the potential parametric setter solution would also break methods like |
Many of our functions are a grid search, or a grid search followed by optimization.
I would like to abstract these with unctions that you pass a
loss
function andsample_dict
and it will do the grid search and optimization appropriately.One point to consider is how to handle the names of parameters that we are
BFGS
-ing over (ieflux
), and which are coordinates to be fixed (dra, ddec
) - these functions should be fully general. The implementation is easy either way but what API do we pick - perhapsloss_param = 'flux'
or some syntax like that to pick out which one we are optimizing?The text was updated successfully, but these errors were encountered: