Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
No copy of input and result model in fit #1937
At the moment there are three separate copies:
Clearly this has great potential to confuse users, the more model copies the more complex.
The reason the model copies were introduced was because
So this PR removes all the copying.
Given that parameter values and covar are currrently stored in
For now, I have added asserts to the tests for fit classes we have (
I tried to remove the model copies in dace318 .
Basically - there's something we have to change how especially the Minuit backend works and interacts with the
E.g. we could introduce a
@adonath - Maybe we can do some pair-coding to try and finish this up tomorrow?
@cdeil Even if we remove the model copy, I think the parameters should be copied before running
@adonath and I discussed this question of model copies again. It's a difficult decision which way to go.
We checked how Sherpa works in detail here - they have a two-level
On the other hand, we checked that Astropy does make a model copy on start in the fit call. So that's a valid way to go also, and they also have complex parameter linking and compound models. But they don't have caching, and they only have a single
Given that state of understanding, I'm +1 to continue with this PR and to not make copies. I also prefer it as a user in notebooks or ipython or scripts, I find it easier to have one model and do several operations with it (like freeze parameters, fit the rest, unfreeze, fit again, ...), and to explicitly call copy() only if needed. @adonath is 50:50, could go either way.
The way that sherpa avoids changing the best-fit parameters e.g. in
@registerrier @adonath @AtreyeeS and anyone interested - please keep thinking about how Gammapy models should work, especially in the context of multiple datasets and background models, and then write a PIG for this soon and we try to prototype that ASAP. My guess is that the global model solution a la Sherpa will be complex and at times problematic and error-prone, but effectively still the best and the route we choose, because making copies all the time is worse.
@cdeil I added a