jonlachmann / gmjmcmc Goto Github PK

When starting gmjmcmc it should be possible to:

• Manually specify the set of covariates that should be included in the first population.
• Randomly select a set number of features for the first population.

This allows the algorithm to work with "wide" data where it is not feasible to include all covariates in the initial population.

Proposals should be updated with a rolling MCMC estimate based on the current run.

See title.

At the moment we are using the standard GLM function in R for likelihood computation. It might be more efficient to use the one available from BAS (as Aliaksandr has done before), or completely implement a slimmed version of it that can have additional features to make it more efficient for our purposes.

We should have a function that

• Run multiple threads of gmjmcmc from a single function call
• Add the possibility to save the parallel results to files
• Add a neat way to pass the results to the merge.results function

Set defaults to make main algorithm function easier to begin with

Simulated Annealing, Greedy algorithm and MT MCMC must be implemented to be able to continue testing.

Would it be useful to standardize the precalculated features of each pop? If so, (probably true) implement it.

add a warning when pop size is below max.pop at the end

see the tile

global transforms for printing the feature

summary(result)
Importance | Feature
##############################| sigmoid(1+1x5+1x5)
#########################| x2
##############################| x4
##############################| x5
##############################| x6
##############################| x7
##############################| x9
##############################| sigmoid(1+1x3+1x7+1x4+1x5)
##############################| x8
##############################| x1

Best population: 7 log marginal posterior: -7342.925
Report population: 10 log marginal posterior: -7342.925

                feats.strings marg.probs

1 sigmoid(1+1x5+1x5) 1.0000000
2 x4 1.0000000
3 x5 1.0000000
4 x6 1.0000000
5 x7 1.0000000
6 x9 1.0000000
7 sigmoid(1+1x3+1x7+1x4+1x5) 1.0000000
8 x8 1.0000000
9 x1 1.0000000
10 x2 0.8519006

If you continue running the code, then the second time calling summary(result) yields

summary(result)
Importance | Feature
##############################| p0(1+1x5+1x5)
#########################| x2
##############################| x4
##############################| x5
##############################| x6
##############################| x7
##############################| x9
##############################| p0(1+1x3+1x7+1x4+1x5)
##############################| x8
##############################| x1

Best population: 7 log marginal posterior: -7342.925
Report population: 10 log marginal posterior: -7342.925

           feats.strings marg.probs

1 p0(1+1x5+1x5) 1.0000000
2 x4 1.0000000
3 x5 1.0000000
4 x6 1.0000000
5 x7 1.0000000
6 x9 1.0000000
7 p0(1+1x3+1x7+1x4+1x5) 1.0000000
8 x8 1.0000000
9 x1 1.0000000
10 x2 0.8519006

Implementation of three techniques from the paper by Hubin et. al. and the fully Bayesian version.

Add wrapper functions which make it easy to run some standard models:

• Bayesian GLM
• BGNLM
• Logic regresssion
• Fractional polynomial
• Cox regresssion
• ...

Given a result from gmjmcmc, a function for prediction should be implemented, doing the following

1. For the top N models in every thread make a prediction.
2. Weight the predictions w.r.t. to the renormalised posteriors.
3. Weight the aggregated posteriors across the threads (in the same way as when merging results).

GMJMCMC and MJMCMC do the same thing when running MJMCMC, this should be one function, which is called from either algorithm.

see the tile

a bit far fetched, yet nice to have in the future

I am now running a parallel version on 40 cores. For some reason this takes much longer than the single core run although I am using more or less the same parameter settings. Is there any chance to get some idea about the progress of the algorithm even in case of using several cores? Perhaps some kind of information from each core when it goes into the feature generation mode of gmjmcmc? Something like

C1P1
C2P1
C3P1
C2P2

where C is the core and P relates to the population which is newly generated.

Should private functions have roxygen2 documentation, or can it perhaps be excluded?