How about a hybrid of “fix it up for the user” and “train the user to do it
right” by checking for “survival::”, generating an informative warning message,
removing it and proceeding with execution.
Two birds, one stone 😊
-G
--
Change your thoughts and you change the world.
--Dr. Norman Vincent Peale
> On Aug 27, 2024, at 10:04 AM, Ben Bolker <bbol...@gmail.com> wrote:
>
> I don't see a big downside, but I will say that there's always a bit of a
> tradeoff between "train the users to do it right" (by writing clear
> documentation and informative error messages) and "make things easy for the
> user" (by making the code more complicated to handle things for them
> automatically).
>
> For example, part of me wishes that (1) there were only one way to provide
> a response variable for a binomial variable with N>1 (preferably by
> specifying proportions and a weights argument) and (2) grouping variables in
> lme4/nlme/et al always had to be specified as factors (rather than
> automatically being coerced to factors). Making those decisions would avoid
> so much code complexity ... (and eliminate one class of errors, i.e. people
> including a continuous covariate as a random-effect grouping variable because
> they think of 'random effect' and 'nuisance variable' as synonyms ...)
>
> But taking the "train the users to do it right" path does also involve more
> discussion with users ("if your software knows what I should be doing why
> can't it just do it for me?")
>
> cheers
> Ben Bolker
>
>> On 2024-08-27 9:43 a.m., Therneau, Terry M., Ph.D. via R-devel wrote:
>> You are right of course, Peter, but I can see where some will get confused.
>> In a formula
>> some symbols and functions are special operators, and others are simple
>> functions. That
>> is the reason one needs I(events/time) to put a rate in as a variable.
>> Someone who
>> types 'offset' at the command line will see that there actually IS a
>> function behind the
>> scenes.
>> Does anyone see a downside to Bill Dunlap's suggestion where the first step
>> of my formula
>> processing would be to "clean off" any survival:: modifiers? That is,
>> something that
>> will break? After all, the code already has a lot of "if (....) " lines
>> for other common
>> user errors. I could view it as just saving me the time to deal with the
>> 'we found an
>> error' emails. I would output the corrected version as the "call"
>> component.
>> Terry
>>> On 8/27/24 03:38, peter dalgaard wrote:
>>> In my view, that's just plain wrong, because strata() is not a function but
>>> a special operator in a model formula. Wouldn't it also blow up on
>>> stats::offset()?
>>>
>>> Oh, yes it would:
>>>
>>>> lm(y~x+offset(z))
>>> Call:
>>> lm(formula = y ~ x + offset(z))
>>>
>>> Coefficients:
>>> (Intercept) x
>>> 0.7350 0.0719
>>>
>>>> lm(y~x+stats::offset(z))
>>> Call:
>>> lm(formula = y ~ x + stats::offset(z))
>>>
>>> Coefficients:
>>> (Intercept) x stats::offset(z)
>>> 0.6457 0.1078 0.8521
>>>
>>>
>>> Or, to be facetious:
>>>
>>>> lm(y~base::"+"(x,z))
>>> Call:
>>> lm(formula = y ~ base::"+"(x, z))
>>>
>>> Coefficients:
>>> (Intercept) base::"+"(x, z)
>>> 0.4516 0.4383
>>>
>>>
>>>
>>> -pd
>>>
>>>> On 26 Aug 2024, at 16:42 , Therneau, Terry M., Ph.D. via
>>>> R-devel<r-devel@r-project.org> wrote:
>>>>
>>>> The survival package makes significant use of the "specials" argument of
>>>> terms(), before
>>>> calling model.frame; it is part of nearly every modeling function. The
>>>> reason is that
>>>> strata argments simply have to be handled differently than other things on
>>>> the right hand
>>>> side. Likewise for tt() and cluster(), though those are much less frequent.
>>>>
>>>> I now get "bug reports" from the growing segment that believes one should
>>>> put
>>>> packagename:: in front of every single instance. For instance
>>>> fit <- survival::survdiff( survival::Surv(time, status) ~ ph.karno +
>>>> survival::strata(inst), data= survival::lung)
>>>>
>>>> This fails to give the correct answer because it fools terms(formula,
>>>> specials=
>>>> "strata"). I've stood firm in my response of "that's your bug, not
>>>> mine", but I begin
>>>> to believe I am swimming uphill. One person responded that it was
>>>> company policy to
>>>> qualify everything.
>>>>
>>>> I don't see an easy way to fix survival, and even if I did it would be a
>>>> tremendous amout
>>>> of work. What are other's thoughts?
>>>>
>>>> Terry
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Terry M Therneau, PhD
>>>> Department of Quantitative Health Sciences
>>>> Mayo Clinic
>>>> thern...@mayo.edu
>>>>
>>>> "TERR-ree THUR-noh"
>>>>
>>>> [[alternative HTML version deleted]]
>>>>
>>>> ______________________________________________
>>>> R-devel@r-project.org mailing list
>>>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fr-devel&data=05%7C02%7Ctherneau%40mayo.edu%7C7659a5f0f0d34746966a08dcc6739fed%7Ca25fff9c3f634fb29a8ad9bdd0321f9a%7C0%7C0%7C638603447151664511%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=UAkeksswfFdLwOdzQIOXUPC2Ey255oW%2FX41kptNZNcU%3D&reserved=0
>> [[alternative HTML version deleted]]
>> ______________________________________________
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
> --
> Dr. Benjamin Bolker
> Professor, Mathematics & Statistics and Biology, McMaster University
> Director, School of Computational Science and Engineering
> > E-mail is sent at my convenience; I don't expect replies outside of working
> > hours.
>
> ______________________________________________
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
[[alternative HTML version deleted]]
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
