ast0815 / remu Goto Github PK

Does not follow the general design at the moment. It treats the response matrix separate from the parameter translator, while now everything is a Predictor.

Some of the classes are pretty heavy. Might want to think about refactoring some of the methods to live somewhere else. At the very least the plotting methods seems to be a prime candidate for this.

To ensure a maximum data shelf life, we should support storing everything in a neat, self-explanatory text format.

Right now the options dictionary is completely replaced rather than updated.

Matplotlib should only be loaded when plotting and PyMC is only needed when actually doing an MCMC.

Right now this is a mess.

If I source remu from a new location I rebuild the virtual environment in that location.

Using Pandas as input and output handler would make ReMU support a lot of standard file formats.

Rather than (mis)using LinearBinnings, often it would be handy to just have category bins. E.g. spcific bins for reaction type enums, or text fields.

It might be useful to have a "one file stores all" format for sharing matrices, instead of the current "the needed information is spread over multiple files" approach.

Simple hypotheses can be added, because they are just vectors of values, i.e. arrays. It could be useful to also add composite hypotheses. The result would be a new composite hypothesis with the parameters of both input hypotheses.

Useful for cases where available matrices are not equally likely.

Docstrings are good, but a proper website (readthedocs?) would be better.

Could speed things up with a mapper.

Someone needs to do an actual publication using ReMU. We will freeze version 1.0 for that first publication.

So far they are not actually used for anything. Should maybe just be removed.

Right now the subbinning marginalisation is handled separately from the marginalisation for plotting puposes. The plotting marginalisation functions should also be applied in one swoop to the subbinning entries, instead of marginalising the subbinnings first.

See above. Might be useful for approximate solutions.

The documentation about the insertion and marginalisation of subbinnings is a bit unclear. It should be made more obvious that they do not change the object itself, but only return a modified clone.

It would be useful to create model comparisons without data, i.e. determine whether two models are distinguishable given a detector response.

Hi ,

When i try to use the method for merging the bins of the truth binning (or equivalent the method to compute the squared mahalanobis distance) i got Memory Error if my number of reco bins are to high.

As this method need to generate a number of random matrix wich depend of the number of reco bins, maybe the issue is coming from this.

Best regards,

Likelihood Machine is an unwieldy name. This software deserves something better.

Ideas:

• Likelihound
• Smearfic

I have not looked at the examples in a while. Need to make sure they work and represent the intended workflow for v1.0.

They make no sense.

This could be used to include external measurements in the fit.

Might be broken?

This could speed up fitting quite a bit.

Might it be better to model the weights of events in a matrix bin as log-normal distributed, rather than normal distributed?

I.e. not just Cartesian products of 1D binnings.

Could make use of available functionality:

https://github.com/scikit-hep/histbook

See above. Probably more useful than the Posterior Distribution of the Likelihood Ratio, according to statisticians.

We re doing a lot of matrix multiplying here. Running this on a GPU might speed things up. Possible packages to facilitate this:

• Numba
• CuPy
• cudamat
• PyTorch

Right now the MCMC trace plotting functions are only working for MCMCs where all truth bins are free parameters directly. This should be made usable for all sorts of CompositeHypotheses.

Fitting works much better when everything is scale ~1 and not e.g. ~1e-38. Would be convenient if the maximisers just handle this automatically.

Should make it work in the general case, as the Builder produces sparse arrays by default.

We need a helper class to deal with flux uncertainties:

• User provides XSEC prediction for each neutrino energy bin.
• Helper class uses flux prediction and covariance matrix (and target mass uncertainty?) to generate randomly varied event rate predictions.
• Set of predictions is fed to LikelihoodMachine to calculate p-values etc.

It might be a good idea to support ROOT files/trees as inputs to fill Binnings. A lot of particle physics experiments use root files as de-facto standard of data exchange.

Useful for more compact data releases.