Pietro Vertechi

Cool! I have Cox working in your package. I'll polish it and make a PR in the next few days. One question though: how do you want to integrate your...

I see. I got it to work without a dependency in DataFrames, in a way that ``` using Survival, DataFrames StatsBase.fit(Survival.CoxModel, @formula(event ~ fin+age+race+wexp+mar+paro+prio) ,rossi) ``` works, except for one...

I see, then with the hack that the formula needs to be called with the `0+...` I think I can reproduce the same structure as GLM does to manage and...

Almost, The issue is that I have to compute the coeftable for the CoxModel (leaving in my package and being independent from DataFrames), without having access to the formula/ModelFrame, so...

100% agreed. I think this only is an issue because a dependency on DataFrames is much heavier than a dependency on some lightweight package like StatsModels. On a separate note,...

I'm unsure that my implementation will be better than yours... I guess one could have an `update_function(::Type{T}, k, n) where T` that would be overloaded for every estimator (KaplanMeier, NelsonAalen...)....

I think we would need to first overload `parse` for EventTime. Something like: ```julia Base.parse(T::Type{EventTime{S}}, str::String) where {S} = endswith(str, '+') ? EventTime(parse(S, chop(str)), false) : EventTime(parse(S, str), true) ```...

Nice! I think it's very important to also refactor the code, as there is one extra measure, which should be computed in a very similar way ([cumulative hazard](https://en.wikipedia.org/wiki/Nelson%E2%80%93Aalen_estimator)) that you...

It's true that this is overlapping but distinct from the issue of deciding whether to put some attribute programmatically, as that can be done with the keyword argument splatting trick...

Hey, yes, that's a good idea, I plan to go through my notes and upload them here next week.