removeDoubleColonSurvival (or 'f', as it was shown in the example) could be
changed to only remove the 'survival::' from expressions that involve the
names to be used in specials. E.g., change
if (is.call(expr) && identical(expr[[1]], doubleColon) &&
identical(expr[[2]], survival))
to
specialNam
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 Vince
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
automa
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 pu
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 comm
Am 27.08.24 um 11:55 schrieb peter dalgaard:
Yes. A quirk, rather than a bug I'd say. One issue is that the internal logic
of transform() relies on
e <- eval(substitute(list(...)), `_data`, parent.frame())
tags <- names(e)
so untagged entries in ... will not be included.
... unless
It could be enhanced to handle data frame argos. Unnamed args are
currently just ignored so adding such would be backwards compatible.
Any interest in this?
On Tue, Aug 27, 2024 at 5:55 AM peter dalgaard wrote:
>
> Yes. A quirk, rather than a bug I'd say. One issue is that the internal logic
>
Yes. A quirk, rather than a bug I'd say. One issue is that the internal logic
of transform() relies on
e <- eval(substitute(list(...)), `_data`, parent.frame())
tags <- names(e)
so untagged entries in ... will not be included. The other part is a direct
consequence of a quirk in data.fr
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
