[GenABEL-dev] Robust Standard Errors for Cox Proportional Hazard Regression

Wed Jul 25 21:57:09 CEST 2012

Hi Yurii and Lennart,
Thanks for sending these thoughtful replies to my inquiry.

In reply to Yurii's questions:
- I would like changes that I make to be public and incorporated into one
of the branches of the source code.
- I would also like to follow the "normal" path of submitting a patch for
evaluation. I don't necessarily need commit-access to the repository.
- Regarding the version that I should start with:
  -- my natural inclination would be to start with the version in which the
survival analysis is working (1.3.0-fixed or coxph-enabled 0.2.0) and then
turn my attention to what isn't working in 0.2.0.  I guess what I do
depends on the project's desires and the ease to which I can actually get
the statistical tests working (with whatever file input) in 0.2.0. I
haven't seen the 0.2.0 code (locally, I have v.0.1-9e (2011.05.15) and I
haven't even attempted to run survival analysis).

In reply to Lennart's queries:
- I do want to focus on the implementation of the weighted Cox regression.
- I am familiar (in principle) with subversion and have scanned the first
few chapters of the "Version Control with Subversion" book.  We have svn
version 1.4.2 installed on the Broad servers; I'll probably install the
latest version locally.

I don't want to promise that I can fix the filevector problem-- but perhaps
the problem will become clear while working with the Cox regression module.

~Alisa

On Wed, Jul 25, 2012 at 9:52 AM, Yury Aulchenko
<yurii.aulchenko at gmail.com>wrote:

> Dear Lennart, Alisa, all,
>
> On Jul 25, 2012, at 10:44 AM, L.C. Karssen wrote:
>
> In short, the status of Cox regression in ProbABEL is the following:
> - In PA 0.2.0 Cox regression is disabled by default because it doesn't
> work correctly (but it can be enabled easily). Looking back it seems
> that it broke with the integration of the filevector/DatABEL code,
> somewhere between the 0.1-3 and 0.1-9 releases.
> - For those who want functional Cox regression (although not with
> filevector data) I suggest to use PA 0.1-3. Recently we've implemented a
> bugfix in that code base and we are almost ready to make that version
> available to the public.
>
> So, at the moment we have two code bases. Ideally we would like to get
> the filevector problem solved in the PA 0.2.0 branch (the bugfix from
> 0.1-3 has also been implemented there). If you think you are up to it
> you are more than welcome to see if you can fix the filevector problem
> in 0.2.0!
>
> If you want to focus more on the implementation of the weighted Cox
> regression I guess it's easier to base your work on the 0.1-3-fixes code
> where you can easily make test runs. Once it works you can forward-port
> your improvements to the 0.2.0 branch.
>
> Yurii, do you agree?
>
>
> This is very good summary of where we stand now.
>
> The big decision is whether to
>
> a) start with 0.2.0 and figure out why Cox does not work there (and then
> proceed to inclusion of robust and weighted). This may take time - we do
> not quite have a clue why it does not work.
>
> or
>
> b) start directly with 1.3.0-fixed (which is due to be released soon) and
> incorporate robust and weighted,  I think, must be relatively
> straightforward because actually the code is there, it is only that we do
> not pass right arguments and data for the code to do the job
>
> A bit of problem with "b" is of cause that we will be getting more and
> more into that branch (which, because it can not use DatABEL/filevector
> format, is very RAM-demanding, while 0.2.0 can operate with <1Gb RAM). On
> the other side, if the thing which really matters is to get this
> functionality ASAP, and RAM is no concern, (b) is clearly the way to go. As
> Lennart mentioned, other possibility is to do (b) then go for (a) - though
> merging branches could be a nightmare.
>
> Under any scenario you decide upon, we will be happy to help in planning
> and implementation (but see below).
>
> Alisa, to make things clear from the start - do you plan to release you
> modifications of the code into "open", e.g. incorporate these modifications
> into one of the mainstream branches available for other people as part of
> ProbABEL releases? The reason I ask is that there are examples that people
> make "private" versions which they never release into open and keep for
> their private use. Of cause under latter scenario we have less motivation
> to actively help.
>
>
> On the technical side of things: do you know how to work with
> Subversion? That would make life easier, because then I could set up a
> separate branch for you to work with. So that, once your feature is
> tested and works as expected, we can easily integrate the changes in the
> main branch(es). (If all this sounds like gibberish submitting a patch
> also works :-).)
>
>
> Just to comment: the "normal" procedure would of cause be that people
> first submit a patch and then can request for commit-access to repository.
> On the other side, Alisa already participated in development of ProbABEL.
> And on the final note, the decision of granting commit-access is the
> decision of current active developers (meaning - for ProbABEL - Lennart,
> and, in lesser degree, Maarten and me). I will be happy to go along with
> any decision worked out by Lennart and Alisa :)
>
> best wishes,
> Yurii
>
> -------------------------------------------------------
> Yurii S. Aulchenko, PhD, Dr. Habil
> Director,YuriiA consulting
> Rotterdam, The Netherlands
> yurii [dot] aulchenko [monkey] gmail [dot] com
>
>
> Let us know what you think and if we can be of any help!
>
> Looking forward to your contributions!
>
> Lennart Karssen.
>
>
>
> On 24/07/12 17:26, Alisa Manning wrote:
>
>
> Hello--
>
> In the past, I've been involved in code contributions to ProbABEL
>
> (extracting covariance between regression estimates for snp and snp*E
>
> for interaction tests).
>
>
> I've set aside some time this summer to work on implementing a weighted
>
> Cox regression model in ProbABEL -- the only change that's required in
>
> the code is to implement robust standard error estimation in the cox
>
> proportional hazard functionality.
>
>
> (Aside: I see that this is a feature request)
>
>
> I noticed that the Cox regression model is under active development in
>
> ProbABEL version 0.2.0.  The purpose of this email is to check in with
>
> the group regarding my plan:
>
>
> 1) check out some latest developers version of the code
>
> 2) play around with the coxph code (if it isn't fixed)
>
> 3) evaluate and test in a statistical fashion (I am a biostatistician
>
> after all!)
>
> 4) implement robust standard error estimation
>
> 5) submit patch for review
>
>
> Comments and ideas are welcome.
>
>
> Thanks!
>
> Alisa
>
>
> --
>
>
> Alisa Knodle Manning, Ph.D.
>
> Postdoctoral Research Fellow
>
> Broad Institute
>
> 617-714-7662
>
> amanning at broadinstitute.org <mailto:amanning at broadinstitute.org<amanning at broadinstitute.org>
> >
>
>
>
>
> _______________________________________________
>
> genabel-devel mailing list
>
> genabel-devel at lists.r-forge.r-project.org
>
> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/genabel-devel
>
>
>
> --
> -----------------------------------------------
> dr. L.C. Karssen
> Erasmus MC
> Department of Epidemiology
> Room Ee-2224
>
> Postbus 2040
> 3000 CA Rotterdam
> The Netherlands
>
> phone: +31-10-7044217
> fax: +31-10-7044657
> e-mail: l.karssen at erasmusmc.nl
> GPG key ID: 0E1D39E3
> -----------------------------------------------
>
>
>
> _______________________________________________
> genabel-devel mailing list
> genabel-devel at lists.r-forge.r-project.org
> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/genabel-devel
>
>
>

-- 

Alisa Knodle Manning, Ph.D.
Postdoctoral Research Fellow
Broad Institute
617-714-7662
amanning at broadinstitute.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/genabel-devel/attachments/20120725/6d1b089b/attachment.html>