CoxTimeVaryingFitter() raising `ZeroDivisionError: float division by 0`
See original GitHub issueHi there,
I’m looking to fit a simple time-varying model using CoxTimeVaryingFitter()
using a cumulative sum of an event occurring. However, every attempt at using the .fit()
method results in a ZeroDivisionError: float division by zero
. I’ve attached a sample XLSX of what a few of the observations I’m using look like:
gh_issue.xlsx.
The code for fitting looks like this:
import numpy as np
import pandas as pd
from lifelines import CoxTimeVaryingFitter
df_fit = pd.read_excel("gh_issue.xlsx")
ctv = CoxTimeVaryingFitter()
ctv.fit(df_fit, id_col="ID", event_col="Event", start_col="Start", stop_col="Stop", show_progress=True)
The error appears to be with weighted_average = weight_count / tied_death_counts
when calling self._get_gradients()
. Is this intended behavior? If so, what is it signifying to the user?
Cheers, Indiana
Issue Analytics
- State:
- Created 4 years ago
- Reactions:2
- Comments:7 (4 by maintainers)
Top Results From Across the Web
ZeroDivisionError: float division by zero tried to resolve but failed
Since the "divide by zero" scenario appears to happen if length is equal to "1". Share.
Read more >CoxTimeVaryingFitter — lifelines 0.27.4 documentation
This is an eyeball test for violations. This will slow down the function significantly. p_value_threshold (float, optional) – the threshold to use to...
Read more >ZeroDivisionError: float division by zero - MetaPhlAn
Hi, When I used the code “metaphlan e1_1.fastq,e1_2.fastq --bowtie2out e1.bowtie2.bz2 --nproc 6 --bowtie2db ~/database/metaphlan_databases/ ...
Read more >zerodivisionerror: float division by zero pandas - ms.fr.edu.vn Search
22 Apr 2022 · The Python "ZeroDivisionError: float division by zero" occurs when ... CoxTimeVaryingFitter() raising `ZeroDivisionError: float division by 0` ...
Read more >ZeroDivisionError: float division by zero when applying "O2"
I'm trying to apply gradient compression with mixed-precision training (amp, mode = “O2” with dynamic loss scale), however I encounter with ...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Looking at events that occur exactly at the time of death think this would depend on what the event is. If it’s a perfect correlation with “death” (heart rate = 0, clicks the ‘Delete Account’ button in a SaaS example), then we would have convergence problem (I ran into this in a similar but unrelated piece of work using the R package
survival
). Otherwise, that event might be a clear indicator of why patient/customer would die/leave.Does this question pertain to covariates changing over time or would it include categorical information to discard as well?
This also raises the question of instantaneous events at the beginning of a timeline as well. In my example, I’ve added 1 so that there is no instantaneous events at t=0, all starting events should start at t=1. Would this suggest that it makes sense to do the same for a death event?
I need to think more about the following question:
i) Are the data record at time t+1 “allowed” in the inference? ii) What if we had looked at measurements at time t instead? t-1?
It seems silly to discard this row, but there are very valid cases where it makes sense to. Ex: if the measurement is heart rate, then at t+1 heart rate =0, and our inference will strongly suggest that “0 heart rate => death”, which is reverse causality.
What I’m trying to determine is if I should keep observations that land on exactly the time of death, or should they be discarded (implicitly or explicitly by the user).