Define FitResult class

[redeboer]

Some thoughts:

• The dict that is currently returned is not convenient from a user perspective and hard to debug
• See refactor: log optimize process via callbacks #164 (comment): it may solve the parameters, estimator_value problem
• Challenge will be to be general enough for different optimisers.
• It could serve of a placeholder for iterations. Currently (refactor: log optimize process via callbacks #164, feat: add intermediate result YAML saving #154), iterations are updated by each callback instance separately.

[jonas-eschle]

What is exactly the purpose of the FitResult? Because in zfit we already define a fitresult API and in general it would be nice to converge on all this APIs if there isn't a good idea why to deviate.

What should the FitResult roughly do?

[redeboer]

Not sure yet, it serves more as a note in the ticket system.

[redeboer]

Background is this discussion #164 (comment)

[spflueger]

List of things the FitResult has to be able to do (in my opinion):

• Store all info, which initialized the fit (initial parameters) and the final state of the process (final parameters). I would also include an estimator value, here. (These things would be common to any kind of Optimizer)
• [Optional/Optimizer dependent] Store infos like error estimates. Some Optimizers cannot directly provide this info. Therefore this info would have to be obtained by running a second Optimizer afterwards (or some code which can determine the errors).
• [Optional/Optimizer dependent] All setting information of the Optimizer. The use case for this is to be to be able to keep track of different fits that have been performed.

That are all the requirements I can come up with. The current solution with the dict is just a "placerholder" solution, but it already encapsulates the idea. That is the FitResult should be a simple datastructure without any logic. I currently do not see any downside to this. The advantage is that things are very simple and yet flexible. Not sure what you think about this @mayou36

The implementation is another quite difficult question. I even opened a stack overflow thread for this a while ago, with no real conclusion. In ComPWA (c++) we picked a templated version of a FitResult. So this would correspond to a Generic class here. The idea was to include info in the Generic base of FitResult, that is common to FitResults from any possible Optimizer. This would be info like the initial and final parameters, or runtime, etc. Any Optimizer specific info would be injected in the result via the Generic.

A dict would be an alternative solutions (could be used also in class and be a substitute for the Generic).

[jonas-eschle]

Hey, sorry for the late reply, I missed your answer! So what we have in zfit is a class FitResult and we solved it the following way

There are mandatory attributes including:

• fmin
• edm
• converged
• valid
• info (dict with a lot of, and arbitrary, information
• params (holds all the infos: value, uncertainties etc)
  together with two methods that can be executed, the info from the is added to the params dics
• hesse (error with hessian approximation)
• errors (minos-like error estimation, but can be completely independent)

All the additional information is stored in the info and can be arbitrary. This is where uncertainties from the minimizer are stored.

With time, more attributes can be added. Whateve we see is needed.

And the dicts basically solve all the problems of fixed structures (Python FTW).