[BioC] mergeLevels (aCGH) vs. MergeLevels.new

[J-C. Marioni]

Hi Ramon,

Like you, I'm a little puzzled by this. mergeLevels.new
should be the function Jane wrote. However, clearly something has gone
wrong in our implementation or an old version of the code has been
uploaded into BioConductor. While the functions (mergeLevels and
mergeLevels.new) are clearly quite similar, there are differences. The
fault is almost certainly with us and I will endeavour to sort out the
problem ASAP.

Thanks for pointing this out.
John

>Dear All,
>
> I am confussed about the differences between mergeLevels (in package 
> aCGH) and MergeLevels.new (package snapCGH), and which one is the 
> recommended merging procedure to use.
>
> By the description in the help, mergeLevels (aCGH) is the one used in the 
> Willenbrock & Fridlyand Bioinformatics 2005 paper. The defaults of 
> mergeLevels (Wilcoxon p-value, Ansari p-value, etc) are also those used 
> in the Bioinformatics paper. And the Bioinformatics paper is cited in the 
> help.
>
> MergeLevels.new (snapCGH) is the function called by mergeStates (also in 
> package snapCGH) when MergeType = 1. I think MergeLevels.new is clearly 
> NOT doing what is described in the Bioinformatics paper: that paper is 
> not cited in the help, the defaults of the algorithm are different, and 
> even the workings of the algorithm seem to differ.
>
> I am confussed, because from the help of mergeStates that says "1 uses a 
> new merging algorithm developed by Hanni Willenbrock and Jane 
> Fridlyand.", it would seem that MergeLevels.new is the recommended way to 
> go. But option 2 (i.e., MergeLevels.old) is not the same as mergeLevels 
> from aCGH either (it seems to be the former merging algorithm in the JMVA 
> paper by Fridlyand et al.).
>
> So, there are three algorithms, mergeLevels (aCGH), MergeLevels.new 
> (snapCGH) and MergeLevels.old (snapCGH). Among the first two, which one 
> should be used? And, if MergeLevels.new is the currently recommended one, 
> are there any references?
>
>
>
>Thanks,
>
>R.
>
>