ConsensusInputRanker more flexible

[Peter]

There are two options that are hard coded in the ConsensusInputRanker?. I think the ConsenusInputRanker? would be more flexible and more usable if these instead could be set by the user by passing functors.

At time being we are sorting on the median of the ranks, and obviously the two parameters are median and ranks. I think these should be set by the user and not hard-coded. For example I have a use case where I wanna sort on the median of score instead (SNR scores to be specific). The reason I wanna do that is because it would allow me to estimate the FDR. Having the median of rank as a measure simply disqualifies any estimation of FDR.

Using the median would still be my option, but if the ConsensusInputRanker? was more flexible and could e.g. sort with respect to minimum rank, one could use to answer questions like whicg features are significant in all x datasets.

[Peter]

(In [666]) refs #151, added IRRetreive functors and prepared ConsensusInputRanker? for usage.

[Peter]

(In [667]) refs #151 using Functor now in consensusinputranker to retrieve information from inputranker to sort on. Median is still hard-coded so I leave this ticket open.

[Jari Häkkinen]

Removing type "idea" and changing this to a "request".

[Peter]

The median could be passed as a functor. The functor needs should have

double operator()(vector<double>& vec);

or using a more STL like style

double operator()(RandomAccessIterator first, RandomAccessIterator last);

The functor should be passed as in constructor of ConsensusInputRanker?. But the question is should the functor be in an inherited structure or should ConsensusInputRanker? be templatized.

Also we have to decide whether there should be a default behaviour. One could e.g. use median as default, which means we have a constructor taking no functor and constructor itself creates a median functor.

Whatever we choose, I think we should replace the constructors taking a Sampler with add functions. In other words, when using ConsensusInputRanker? first a constructor is called defining which IRRetriever and Median (or look a like) that will be used, and then Sampler (with data) or a InputRanker? are added. I think this is more logical.

[Markus Ringnér]

If we templatize ConsensusInputRanker? (CIR) this means functions that take such an object will be less flexible. Say I have a function f(const CIR &) now, then it has to be changed to f(const CIR<median>&) which makes it hard to get the flexibility you are looking for. If I am correct I vote for the functor being an inherited structure and not for templatized CIR.

Also, if I understand Peter correctly there is nothing in what is being suggested that makes it difficult for the functor to use the information from the InputRankers? to get a consensus based on say the product of all ranks rather than selecting one such as the median rank. What I mean is in

double operator()(vector<double>& vec);   

vec is a vector of all ranks for a gene and the product is as simple to return as the median. Correct?

[Peter]

Great.

Yes, a problem with templates is that they tend to propagate unless superb design. STL is great. Yes, the only functionality of the functor is to take a vector<double> and return a double. In mathematical terms, the functor is a function from R^{N to R, and the product of all terms is a trivial example of such a function.}

The reason we have vector<double> is because the other generalization mention above. The vector is filled using an IRRetrieve functor which returns a double (could e.g. be the score)

[Peter]

(In [827]) added Functors to be used in CIR. Refs #151

[Peter]

(In [828]) Generalized ConsenusInputRanker?, Fixes #151