jackdunger / oxsx Goto Github PK

Maybe a bit of overkill but I just want to put things in one place.

The plan is to write a VaryingParameterPDF (VpPDF) class that allows a convolution's underlying function to depend on the parameters it convolving about.

The idea is that you should make the VpPDF, set a kernel and then tell the VpPDF how each parameter varies given the bin centres of those bins:
VpPDF smear;
smear.SetKernal(&gaus);
smear.Depend("parameterName", function);

Inheritance:
CDF->VpPdf

Contains :
integral(x_l,x_h,x_c);
std::mapstd::string,Function* dict;<- This is a dictionary of parameterNames to parameter functions (sigma= a sqrt(E) + b)
ParameterDict parameters;
CDF* pdf;

The code should be able to infer the dimensionality of the histogram and do the right thing, the fact you want a ROOT can also be inferred from the extension

if DataSetGenerator::fBootStrap == true the generator should sample from the original data sets with replacement.

Currently, an ND Gaussian assumes that its arguments are uncorrelated so that the probability is equal to the product of the individual Gaussians. This should be extended to the correlated case:

• The Gaussian can be initialized using the correlation matrix, from which it could infer the dimensionality
• The exponent should then be calculated using matrix multiplication

While adapting to the new naming conventions, i spent some time finding an error that was ultimately caused by old files from a previous build being in the include folder.

When running "scon -c" only target files are removed. Looking at the documentation there exist ways of deleting files not in the target list :
http://scons.org/doc/production/HTML/scons-user.html#idm139837640441408

However its not immediately obvious, to me anyway, where this "Clean" function should go.

This should be open source, with no licence others currently cannot use this software

Currently the MetropolisHastings method keeps track of the samples using histograms/vectors. What you want here really depends on the use case, and the number of samples. This should be separeed

There should be an output data handle interface and then various implementations that the user can choose from: e.g. simple csv, root tree, one big histogram, histograms keeping track of the projections etc.

It might be best to also have a factory class that works behind the scenes so that the user interface can be just choosing a string.

Rather than only relying on people adding optimisation algorithms, we should interface to other numerical libraries for optimisation along with compile options

Looking ahead to easy running on batch systems, code depending on ROOT should be controlled with a compile flag that can be on or off by default.

To bring them inline with the new interface

DSGen should produce an accompanying document with the truth content of each data set which can be saved in a single line.

Better: option to add the origin of each event to the data set itself

Already supports TNtuple but uses no features that can't be used for TTree or TChain.
This would allow reading the production data directly - though you'd probably want to prune it anyway

Names like PDF, Cut etc. need protection to avoid clashes with other libraries. We should put all the classes inside a library wide namespace

Rather than an auto generated compile script, users should be able to install a config script that provides the appropriate headers, libraries etc. for easy inclusion in makefiles or in the command line a la root-config