[Rd] broken link to Titanic data
This URL, which appears in the ?Titanic web page: https://www.amstat.org/publications/jse/v3n3/datasets.dawson.html gives me a 404 error. Googling "Dawson titanic data" gives ww2.amstat.org/publications/jse/v3n3/datasets.dawson.html which is similarly broken. Poking around gives this preferred reference URL to the original article on Taylor & Francis's site: https://doi.org/10.1080/10691898.1995.11910499 This article is free to access, but it doesn't appear that it's possible to access the original "titanic.dat.txt" through T&F's web site. It is on the internet archive ... https://web.archive.org/web/20180323070125/https://ww2.amstat.org/publications/jse/datasets/titanic.dat.txt The codebook is at https://web.archive.org/web/20180405163149/http://ww2.amstat.org:80/publications/jse/datasets/titanic.txt I can submit this as a bug report if that's recommended ... Ben Bolker __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] sys.call() inside replacement functions incorrectly returns *tmp*
On Tue, Oct 16, 2018 at 12:03 AM Abs Spurdle wrote: > Probably the best example I can think of is converting cartesian > coordinates to polar coordinates. > Then we might have something like (note, untested, written in my email): > cart2polar = function (x, y) > list (theta=atan (y / x), r=sqrt (x * x + y * y) ) > > massign (r, theta) = cart2polar (x, y) > > Now, I'm considering a multiple assignment operator, so something like: > c (theta, r) $<-$ cart2polar (x, y) This is something that comes up occasionally and as noted by Gabor, has been implemented in packages. But I am not keen on unpacking the return from a function into multiple objects. The reason your `cart2polar` function returns a list of theta and r is because it is returning a polar coordinate, and that coordinate needs both. Why unpack them? If you don't need theta, then do `r = cart2polar(x,y)$r`. If you need theta and r, then keep them together in a single object. If you need to call a function that needs separate theta and r, use `plot(d$r, d$theta)`. Its a bit more typing but that's a false efficiency when you want code to be tidy and well-structured, and to convey meaning. `plot(this$r, this$theta)` is clearly a plot of something to do with `this`, and you can see that the r and the theta are coming from the same thing, whereas a `(r,theta) %=% foo(x,y)` some place and then `plot(r, theta)` somewhere else has broken the connection. Barry __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] sys.call() inside replacement functions incorrectly returns *tmp*
Well,
I think what you want to do is hard if you insist on using a replacement
function, i.e. massign(vars) <- values.
But as you wrote, you can use a modified assignment operator, or you could
write something comparable to assign, so massign(listofvars, listofvalues,
environment) shouldn’t be too hard.
I believe in this context, the term “replacement function” is a bit confusing.
In my experience, replacement functions are for editing a certain aspect of a
variable or object, mostly attributes, or they can replace certain elements.
But in order to edit something, it has to exist in the first place.
It may be that I’m reading it wrong, but to me “massign (x, y, z) = somelist”
reads “I want to edit some aspects of x, y and z, by inputting somelist to
them”. In that guise, I can see some function like mlevels(factor1, factor2,
factor3) <- as.character(1:10), to set the level attributes to all three
factors to the same set of levels.
That’s not something easily supported with replacement functions, but it is
possible.
But for creating new objects, or reassigning them, a replacement function seems
not the way to go to me.
And as Barry noted, why do you want to pull these values apart in the first
place? I guess your example of polar coordinates was just an example, but if
you want to store multiple values that’s a lot easier in a list, and it keeps
your workspace tidier.
For your other point, editing attributes is possible with `attr<-`.
If you want to have it as an infix operator without having to use quotes:
`%$%<-` <- function(obj, attr, value) {
`attr<-`(obj, as.character(substitute(attr)), value)
}
Now “myobj %$% myattr <- values “ will do as you desire
Best regards,
Emil Bode
From: Abs Spurdle
Date: Tuesday, 16 October 2018 at 01:02
To: Emil Bode
Cc: r-devel
Subject: Re: [Rd] sys.call() inside replacement functions incorrectly returns
*tmp*
Kia Ora
> Although I'm not sure what problem it would solve...
Given that you asked, I was interested in writing a multiple assignment
function as a replacement function, so something like:
massign (x, y, z) = construct.some list ()
Obviously, that's not possible.
Probably the best example I can think of is converting cartesian coordinates to
polar coordinates.
Then we might have something like (note, untested, written in my email):
cart2polar = function (x, y)
list (theta=atan (y / x), r=sqrt (x * x + y * y) )
massign (r, theta) = cart2polar (x, y)
Now, I'm considering a multiple assignment operator, so something like:
c (theta, r) $<-$ cart2polar (x, y)
And while we're on the topic, I'm also considering an attribute operator (to
access object attributes), something like:
myobject%$%myattribute
This would be similar to . in C++/Java or @ in S4.
And seems like something obvious that's missing from R.
Implementing an attribute read this way is easy, however, implementing an
attribute assignment this way (without language level support) is difficult.
kind regards
Abs
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] invisible functions
The survival package, like many others, has several helper functions that are
not declared
in the namespace, since their only use is to be called by other "main"
functions of the
package. This works well since the functions in the survival namespace can see
them ---
without ::: arguments --- and others don't.
Until a situation I ran into this week, for which I solicit comments or advice.
The
concordance function is a new addition, and it has one case where the same
underlying
helper function is called multiple times, with many arguments passed through
from the
parent. I thought that this would be a good use for the trick we use for
model.frame, so
I have code like this:
concordance.coxph <- function(fit, ..., newdata, group, ymin, ymax,
timewt=c("n", "S", "S/G", "n/G", "n/G2"),
influence=0, ranks=FALSE, timefix=TRUE) {
Call <- match.call()
.
.
.
cargs <- c("ymin", "ymax","influence", "ranks", "timewt", "timefix")
cfun <- Call[c(1, match(cargs, names(Call), nomatch=0))]
cfun[[1]] <- quote(cord.work)
cfun$reverse <- TRUE
rval <- eval(cfun, parent.frame())
This worked fine in my not-in-a-namespace test bed, but then fails when
packaged up for
real: the code can't find the helper function cord.work! The rule that
survival package
functions can "see" their undeclared helpers fails.
I got it working by changing parent.frame() to environment(concordance) in the
eval()
call. Since everything used by cord.work is explicitly passed in its argument
list this
does work.
Comments or suggestions? (I avoid having survival:: in the survival package
because it
messes up my particular test bed.)
Terry
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] invisible functions
On 16/10/2018 6:42 PM, Therneau, Terry M., Ph.D. via R-devel wrote:
The survival package, like many others, has several helper functions that are
not declared
in the namespace, since their only use is to be called by other "main"
functions of the
package. This works well since the functions in the survival namespace can see
them ---
without ::: arguments --- and others don't.
Until a situation I ran into this week, for which I solicit comments or advice.
The
concordance function is a new addition, and it has one case where the same
underlying
helper function is called multiple times, with many arguments passed through
from the
parent. I thought that this would be a good use for the trick we use for
model.frame, so
I have code like this:
concordance.coxph <- function(fit, ..., newdata, group, ymin, ymax,
timewt=c("n", "S", "S/G", "n/G", "n/G2"),
influence=0, ranks=FALSE, timefix=TRUE) {
Call <- match.call()
.
.
.
cargs <- c("ymin", "ymax","influence", "ranks", "timewt", "timefix")
cfun <- Call[c(1, match(cargs, names(Call), nomatch=0))]
cfun[[1]] <- quote(cord.work)
cfun$reverse <- TRUE
rval <- eval(cfun, parent.frame())
This worked fine in my not-in-a-namespace test bed, but then fails when
packaged up for
real: the code can't find the helper function cord.work! The rule that
survival package
functions can "see" their undeclared helpers fails.
The reason that fails is as follows:
cfun, despite its name, is not a function. It's an unevaluated expression.
You are evaluating it in parent.frame(), which is the caller's
evaluation frame. That frame can't generally see the private frame for
your package.
Since it needs to see things supplied by the user, it needs to see
parent.frame. It doesn't need to see anything in your evaluation frame
other than cord.work, but it can't see that, which is your problem.
I think there are at least two choices:
1. change cfun[[1]] <- quote(cord.work) to cfun[[1]] <- cord.work.
This should work, but error messages may be messed up, because you'll be
calling an anonymous function that is a copy of cord.work, rather than
calling cord.work by name.
2. change cfun[[1]] <- quote(cord.work) to cfun[[1]] <-
quote(survival:::cord.work). You say this will mess up your test bed.
That suggests that your test bed is broken. This is a perfectly legal
and valid solution.
Duncan Murdoch
I got it working by changing parent.frame() to environment(concordance) in the
eval()
call. Since everything used by cord.work is explicitly passed in its argument
list this
does work.
Comments or suggestions? (I avoid having survival:: in the survival package
because it
messes up my particular test bed.)
Terry
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
