-
-
Notifications
You must be signed in to change notification settings - Fork 126
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
censored()
proposal
#577
Comments
Tagging people who showed interest in the topic @don-jil, @ipa. Also tagging you @aloctavodia just in case you want to add something. |
censored2 seems the cleanest to me. Reminds me of the brms implementation.
…On Wed, Oct 19, 2022 at 2:22 PM Tomás Capretto ***@***.***> wrote:
Tagging people who showed interest in the topic @don-jil
<https://github.com/don-jil>, @ipa <https://github.com/ipa>. Also tagging
you @aloctavodia <https://github.com/aloctavodia> just in case you want
to add something.
—
Reply to this email directly, view it on GitHub
<#577 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AH3QQV6RF4UZU7FGNFM4DQDWEA36BANCNFSM6AAAAAARJMLTO4>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
In brms it's |
brms is what I'm familiar with, so that works for me. It will also help other folks who are migrating from R/brms. |
The problem with using |
To me the proposal for censored2 also looks cleanest. I agree with @tomicapretto with the issue on the Cox proportional hazard models in R (which most are very familiar with) use |
That seems intuitive as well. :-) |
Thanks a lot @ipa, @don-jil, and @zwelitunyiswa for your input! |
We have #541 and #543 where models for censored data are discussed. Here I sketch the function we could use to handle censoring. It's inspired by
Surv()
andcens()
from the survival and brms packages in R respectively.Proposal 1
The function has three arguments. The first is the value of the variable, the second is the status ("left", "none", "right", and "interval"), and the third is an optional value that is passed when we use interval censoring.
Dataset 1 Right censoring
Then we can use it as
One "drawback" of this approach appears when we consider interval censoring.
Dataset 1 Interval censoring
We know the value is within an interval, but we don't know the exact value
Here the call would look like
It works well, but what makes it not very appealing to me is that we have "value", "status", "value" in the signature.
But I have another proposal, that I'm calling
censored2()
for now. If this becomes the chosen one, of course it will be namedcensored()
.Notice the only argument is an unnamed argument of variable length. Internally, we check it's of length 2 or 3.
This allows us to do
and
which reads much better to me.
In summary, we have two candidate implementations for
censored()
. They both do the same, but they differ in the signature. One signature has 3 arguments well defined. The first is a value, the second a status, and the third is an optional value. The other signature has a single argument, which is an unnamed argument of variable length. Internally, we handle it differently depending on how many arguments we got. This allows the code to look like (value, status) and (value, value2, status) instead of (value, status, value2).Note: This could be simplified a lot if we decide to support only left and right censoring. At the moment, PyMC supports only those out of the box. Interval censoring still requires more work on our end. I think it's still worth considering interval censoring from the very beginning, because it may be supported at some point.
The text was updated successfully, but these errors were encountered: