SCM

[#1846] Bug in pacoxph functionality of ProbABEL version 0.1-3

View Trackers | Bugs | Download .csv | Monitor

Date:
2012-02-23 17:03
Priority:
3
State:
Closed
Submitted by:
Anne Grotenhuis (anne_grotenhuis)
Assigned to:
Lennart Karssen (lckarssen)
Resolution:
Accepted As Bug
Operating System:
Linux (32bit)
Severity:
major
Hardware:
None
Version:
PA v0.1-3
Component:
ProbABEL
URL:
 
Summary:
Bug in pacoxph functionality of ProbABEL version 0.1-3

Detailed description
Dear all,

I noticed a bug in the ProbABEL pacoxph functionality. I used ProbABEL version 0.1-3, as I already know that there are problems with the pacoxph functionality in later versions of ProbABEL (that use filevector format).

The additive Cox regression model results are different when comparing a run using the example .mlprob (test.mlprob) file to an otherwise identical run using a dose file recreated from the mlprob file (dosage_A = 2 * p_AA + p_AB).
(The dose file was (re)created, because the example dose file (test.mldose) does not match the example prob file (test.mlprob).)

In more detail:
For the test run, the dosage file (probabel.mldose) was generated from the example file "test.mlprob" by the following script:

awk '{ printf "%s MLDOSE", $1; for (i=3; i <= NF; i += 2) printf " %s", (2*$i + $(i+1)); printf "\n"}' test.mlprob

A run with pacoxph using "--dose test.mlprob --ngpreds 2" gives different results than "--dose probabel.mldose --ngpreds 1" (both using the same example mlinfo and phenotype data).

I have the feeling that the bug is specific for using mlprob input format to pacoxph, as the Cox regression results of ProbABEL based on mldose input seem comparable to effect estimates/significance obtained based on Cox regression analysis in SPSS (where results based on mlprob file input show a large discrepancy with SPSS results)

I would really appreciate it if someone could look into this to narrow down the problem and hopefully fix it.

Kind regards,
Anne

Followup

Message
Date: 2012-06-11 07:05
Sender: Lennart Karssen

This bug has been fixed in SVN rev. 902. The code has been forward-ported to trunk. This fix will be released soon in an update to v.0.1-3.

Thanks Anne et al.!
Date: 2012-03-27 21:44
Sender: Lennart Karssen

I have reproduced the bug, therefore I mark it as "Accepted".
Date: 2012-02-24 08:35
Sender: Lennart Karssen

Thanks for this extensive report!

Attached Files:

Changes:

Field Old Value Date By
close_dateNone2012-06-11 07:05lckarssen
status_idOpen2012-06-11 07:05lckarssen
ResolutionNone2012-03-27 21:44lckarssen
Versionother2012-03-26 20:09lckarssen
assigned_tonone2012-03-26 20:09lckarssen
Thanks to:
Vienna University of Economics and Business University of Wisconsin - Madison Powered By FusionForge