[Rd] switching to an previous R engine?
Hello, I have quite a few programs that I have written over the last 5 years that rely on the old R engine (2.6.2 and earlier) returning a null when an invalid index is used, as in: > df <- data.frame(x = 1) > df[,'y'] NULL Is there a way to tell R to return NULLs instead of raising errors within a function or package? I'm a fan of the raising errors instead of returning values that could be confused with a legitimate return value, but for now I'm stuck using 2.6.2 until I have time to check every line of code I've written in the last 5 years. Thanks! Jason Thorpe [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] problem with parse(text=quote(name))
Calling parse(text=quote(name)) or text=as.name("name")
makes parse() prompt for input from the command line
and then it returns a parse of the initial characters
of 'name' (depending on how many characters were typed
at the prompt). E.g.,
> parse(text=quote(myName))
?1/3
expression(myN)
attr(,"srcfile")
> parse(text=quote(myName))
?1/34
expression(myNa)
attr(,"srcfile")
> parse(text=quote(myName))
?1/345
expression(myNam)
attr(,"srcfile")
where the ? lines are where parse prompted for input
and I typed a valid R expression.
I ran into this when starting to convert code that used
a deparse/parse cycle to avoid the cycle by storing the
expressions themselves and I hadn't yet taken out one
of the calls to parse(text=myText).
I see it in 2.10.1 and "R version 2.11.0 Under development
(unstable) (2010-03-07 r51225)."
Bill Dunlap
Spotfire, TIBCO Software
wdunlap tibco.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] scale(x, center=FALSE) (PR#14219)
I'm resending this after a week ... I really don't want to nag, but
I also would not like to see this sink below the waves.
Is there a preferred protocol for requesting comments without nagging
too much? I would add a comment to 14219 (and was curious to see
whether it was rejected) ... I went to bugzilla, and bug 14219 doesn't
seem to exist any more -- either as open or as closed -- don't know if
it got lost, or thrown away, when the bug system migrated?
cheers
Ben Bolker
[re: behavior of scale() when center=FALSE and scale=TRUE]
> Again, I agree with you that the behavior is not optimal, but it is
> very hard to make changes in R when the behavior is sub-optimal rather
> than actually wrong (by some definition). R-core is very conservative
> about changes that break backward compatibility; I would like it if they
> chose to change the function to use standard deviation rather than
> root-mean-square, but I doubt it will happen (and it would break things
> for any users who are relying on the current definition).
[snip]
> I have attached a patch
> file (and append the information below as well) that changes "standard
> deviation" back to "root mean square" and is much more explicit about
> this issue ... I hope R-core will jump in, critique it, and possibly use
> it in some form to improve (?) the documentation ...
>
> [PS: I have written that the scaling is equivalent to sd() "if and
> only if" centering was done. Technically it would also be equivalent if
> the column already had zero mean ...]
>
===
--- scale.Rd(revision 51180)
+++ scale.Rd(working copy)
@@ -41,13 +41,18 @@
equal to the number of columns of \code{x}, then each column of
\code{x} is divided by the corresponding value from \code{scale}. If
\code{scale} is \code{TRUE} then scaling is done by dividing the
- (centered) columns of \code{x} by their standard deviations, and if
+ (centered) columns of \code{x} by their root-mean-squares, and if
\code{scale} is \code{FALSE}, no scaling is done.
-
- The standard deviation for a column is obtained by computing the
- square-root of the sum-of-squares of the non-missing values in the
- column divided by the number of non-missing values minus one (whether
- or not centering was done).
+
+ The root-mean-square for a (possibly centered)
+ column is defined as
+ \eqn{\sqrt{\sum(x^2)/(n-1)}}{sqrt(sum(x^2)/(n-1))},
+ where \eqn{x} is a vector of the non-missing values
+ and \eqn{n} is the number of non-missing values.
+ If (and only if) centering was done,
+ this is equivalent to \code{sd(x,na.rm=TRUE)}.
+ (To scale by the standard deviations without centering,
+ use \code{scale(x,center=FALSE,scale=apply(x,2,sd,na.rm=TRUE))}.)
}
\references{
Becker, R. A., Chambers, J. M. and Wilks, A. R. (1988)
(Bump re: suggested update to scale.Rd . Is this under
consideration? I'll stop pestering if it's considered
unacceptable, just don't want it to vanish without a trace ...)
--
Ben Bolker
Associate professor, Biology Dep't, Univ. of Florida
bol...@ufl.edu / people.biology.ufl.edu/bolker
GPG key: people.biology.ufl.edu/bolker/benbolker-publickey.asc
signature.asc
Description: OpenPGP digital signature
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] scale(x, center=FALSE) (PR#14219)
On Mar 12, 2010, at 1:29 PM, Ben Bolker wrote:
>
> I'm resending this after a week ... I really don't want to nag, but
> I also would not like to see this sink below the waves.
>
It has been closed as feature/FAQ with the note:
"As documented on the help page!"
> Is there a preferred protocol for requesting comments without nagging too
> much? I would add a comment to 14219 (and was curious to see whether it was
> rejected) ... I went to bugzilla, and bug 14219 doesn't seem to exist any
> more -- either as open or as closed -- don't know if it got lost, or thrown
> away, when the bug system migrated?
>
Hmm.. there was apparently an error when importing the feature&FAQ box.
Unfortunately Jitterbug left some duplicate bugs in different categories so the
import was not as easy as it should be. I'll double check the IDs to see if any
others are missing -- I ran import for 14219 manually now.
Thanks,
Simon
>
> [re: behavior of scale() when center=FALSE and scale=TRUE]
>
>> Again, I agree with you that the behavior is not optimal, but it is
>> very hard to make changes in R when the behavior is sub-optimal rather
>> than actually wrong (by some definition). R-core is very conservative
>> about changes that break backward compatibility; I would like it if they
>> chose to change the function to use standard deviation rather than
>> root-mean-square, but I doubt it will happen (and it would break things
>> for any users who are relying on the current definition).
>
> [snip]
>
>> I have attached a patch
>> file (and append the information below as well) that changes "standard
>> deviation" back to "root mean square" and is much more explicit about
>> this issue ... I hope R-core will jump in, critique it, and possibly use
>> it in some form to improve (?) the documentation ...
>>
>> [PS: I have written that the scaling is equivalent to sd() "if and
>> only if" centering was done. Technically it would also be equivalent if
>> the column already had zero mean ...]
>>
> ===
> --- scale.Rd (revision 51180)
> +++ scale.Rd (working copy)
> @@ -41,13 +41,18 @@
> equal to the number of columns of \code{x}, then each column of
> \code{x} is divided by the corresponding value from \code{scale}. If
> \code{scale} is \code{TRUE} then scaling is done by dividing the
> - (centered) columns of \code{x} by their standard deviations, and if
> + (centered) columns of \code{x} by their root-mean-squares, and if
> \code{scale} is \code{FALSE}, no scaling is done.
> -
> - The standard deviation for a column is obtained by computing the
> - square-root of the sum-of-squares of the non-missing values in the
> - column divided by the number of non-missing values minus one (whether
> - or not centering was done).
> +
> + The root-mean-square for a (possibly centered)
> + column is defined as
> + \eqn{\sqrt{\sum(x^2)/(n-1)}}{sqrt(sum(x^2)/(n-1))},
> + where \eqn{x} is a vector of the non-missing values
> + and \eqn{n} is the number of non-missing values.
> + If (and only if) centering was done,
> + this is equivalent to \code{sd(x,na.rm=TRUE)}.
> + (To scale by the standard deviations without centering,
> + use \code{scale(x,center=FALSE,scale=apply(x,2,sd,na.rm=TRUE))}.)
> }
> \references{
> Becker, R. A., Chambers, J. M. and Wilks, A. R. (1988)
>
> (Bump re: suggested update to scale.Rd . Is this under
> consideration? I'll stop pestering if it's considered
> unacceptable, just don't want it to vanish without a trace ...)
>
>
> --
> Ben Bolker
> Associate professor, Biology Dep't, Univ. of Florida
> bol...@ufl.edu / people.biology.ufl.edu/bolker
> GPG key: people.biology.ufl.edu/bolker/benbolker-publickey.asc
>
> __
> 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
[Rd] symbol name caching bug: attributes get tied to symbol names
In R versions 2.10.1 and "2.11.0 Under development (unstable) (2010-03-07 r51225)" on Windows I get the following if I type the commands at the start of the session. Note how the attribute attached to the name "Response" by the initial call to structure() seems to get tied to that name for the remainder of the session: > z <- structure(quote(Response), isResponse=TRUE) > parse(text="Response~Predictor")[[1]][[2]] Response attr(,"isResponse") [1] TRUE > quote(Response~Predictor)[[2]] Response attr(,"isResponse") [1] TRUE > quote(Response) Response attr(,"isResponse") [1] TRUE The attribute actually does go away after quite a while, but I haven't figured out the trigger. rm(z) followed by gc() does not affect it. If I use an unadorned variable called Response before making the structure z, then the isResponse attribute doesn't seem to stick to the name Response. Bill Dunlap Spotfire, TIBCO Software wdunlap tibco.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] symbol name caching bug: attributes get tied to symbol names
Since symbols/names are reference objects this behavior in unavoidable if we allow attributes to be added to them. On the other hand, I'm not sure it makes sense to allow that. Attempting to set an attribute on NULL signals an error; it would probably make sense to do the same for any name object. luke On Fri, 12 Mar 2010, William Dunlap wrote: In R versions 2.10.1 and "2.11.0 Under development (unstable) (2010-03-07 r51225)" on Windows I get the following if I type the commands at the start of the session. Note how the attribute attached to the name "Response" by the initial call to structure() seems to get tied to that name for the remainder of the session: > z <- structure(quote(Response), isResponse=TRUE) > parse(text="Response~Predictor")[[1]][[2]] Response attr(,"isResponse") [1] TRUE > quote(Response~Predictor)[[2]] Response attr(,"isResponse") [1] TRUE > quote(Response) Response attr(,"isResponse") [1] TRUE The attribute actually does go away after quite a while, but I haven't figured out the trigger. rm(z) followed by gc() does not affect it. If I use an unadorned variable called Response before making the structure z, then the isResponse attribute doesn't seem to stick to the name Response. Bill Dunlap Spotfire, TIBCO Software wdunlap tibco.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Luke Tierney Chair, Statistics and Actuarial Science Ralph E. Wareham Professor of Mathematical Sciences University of Iowa Phone: 319-335-3386 Department of Statistics andFax: 319-335-3017 Actuarial Science 241 Schaeffer Hall email: l...@stat.uiowa.edu Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] symbol name caching bug: attributes get tied to symbol names
> -Original Message- > From: l...@stat.uiowa.edu [mailto:l...@stat.uiowa.edu] > Sent: Friday, March 12, 2010 4:24 PM > To: William Dunlap > Cc: r-devel@r-project.org > Subject: Re: [Rd] symbol name caching bug: attributes get > tied to symbol names > > Since symbols/names are reference objects this behavior in unavoidable > if we allow attributes to be added to them. On the other hand, I'm > not sure it makes sense to allow that. Attempting to set an attribute > on NULL signals an error; it would probably make sense to do the same > for any name object. > Thanks Luke, for the explanation. I'm comfortable disallowing attributes on names. The problem arose for me when analyzing a parse tree and I was using attributes to label parts of it. I can stick in a list() layer above the calls, names, etc., to attach the attributes to. That can simplify the syntax also, since things like as.vector() applied to a call object with attributes won't strip the attributes. Bill Dunlap Spotfire, TIBCO Software wdunlap tibco.com > luke > > On Fri, 12 Mar 2010, William Dunlap wrote: > > > In R versions 2.10.1 and "2.11.0 Under development > > (unstable) (2010-03-07 r51225)" on Windows I get the > > following if I type the commands at the start of > > the session. Note how the attribute attached to > > the name "Response" by the initial call to structure() > > seems to get tied to that name for the remainder of > > the session: > > > > > z <- structure(quote(Response), isResponse=TRUE) > > > parse(text="Response~Predictor")[[1]][[2]] > > Response > > attr(,"isResponse") > > [1] TRUE > > > quote(Response~Predictor)[[2]] > > Response > > attr(,"isResponse") > > [1] TRUE > > > quote(Response) > > Response > > attr(,"isResponse") > > [1] TRUE > > > > The attribute actually does go away after quite a > > while, but I haven't figured out the trigger. > > rm(z) followed by gc() does not affect it. > > > > If I use an unadorned variable called Response before > > making the structure z, then the isResponse attribute > > doesn't seem to stick to the name Response. > > > > > > Bill Dunlap > > Spotfire, TIBCO Software > > wdunlap tibco.com > > > > __ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > > -- > Luke Tierney > Chair, Statistics and Actuarial Science > Ralph E. Wareham Professor of Mathematical Sciences > University of Iowa Phone: 319-335-3386 > Department of Statistics andFax: 319-335-3017 > Actuarial Science > 241 Schaeffer Hall email: l...@stat.uiowa.edu > Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] list_files() memory corruption?
I am using R-2-10 from subversion. In the implementation of do_listfiles() in platform.c, it appears to allocate a vector of length count where count is calculated by count_files(). It then proceeds to call list_files(), passing in the vector but not the value of count. Yet list_files() doesn't seem to check the length of the vector that was allocated. What happens if a new file was added to the file system between the call to count_files() and list_files()? Doesn't this write past the length of the allocated vector? -- __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] scale(x, center=FALSE) (PR#14219)
Thanks Simon!
How irritating/wrong would it be if I opened a new bug to submit my
suggested documentation patch? As detailed below, I think the
documentation is somewhat confusing (it depends on a highly non-standard
definition of "standard deviation" ...)
cheers
Ben Bolker
Simon Urbanek wrote:
> On Mar 12, 2010, at 1:29 PM, Ben Bolker wrote:
>
>> I'm resending this after a week ... I really don't want to nag, but
>> I also would not like to see this sink below the waves.
>>
>
> It has been closed as feature/FAQ with the note:
> "As documented on the help page!"
>
>
>> Is there a preferred protocol for requesting comments without nagging too
>> much? I would add a comment to 14219 (and was curious to see whether it
>> was rejected) ... I went to bugzilla, and bug 14219 doesn't seem to exist
>> any more -- either as open or as closed -- don't know if it got lost, or
>> thrown away, when the bug system migrated?
>>
>
> Hmm.. there was apparently an error when importing the feature&FAQ box.
> Unfortunately Jitterbug left some duplicate bugs in different categories so
> the import was not as easy as it should be. I'll double check the IDs to see
> if any others are missing -- I ran import for 14219 manually now.
>
> Thanks,
> Simon
>
>
>> [re: behavior of scale() when center=FALSE and scale=TRUE]
>>
>>> Again, I agree with you that the behavior is not optimal, but it is
>>> very hard to make changes in R when the behavior is sub-optimal rather
>>> than actually wrong (by some definition). R-core is very conservative
>>> about changes that break backward compatibility; I would like it if they
>>> chose to change the function to use standard deviation rather than
>>> root-mean-square, but I doubt it will happen (and it would break things
>>> for any users who are relying on the current definition).
>> [snip]
>>
>>> I have attached a patch
>>> file (and append the information below as well) that changes "standard
>>> deviation" back to "root mean square" and is much more explicit about
>>> this issue ... I hope R-core will jump in, critique it, and possibly use
>>> it in some form to improve (?) the documentation ...
>>>
>>> [PS: I have written that the scaling is equivalent to sd() "if and
>>> only if" centering was done. Technically it would also be equivalent if
>>> the column already had zero mean ...]
>>>
>> ===
>> --- scale.Rd (revision 51180)
>> +++ scale.Rd (working copy)
>> @@ -41,13 +41,18 @@
>> equal to the number of columns of \code{x}, then each column of
>> \code{x} is divided by the corresponding value from \code{scale}. If
>> \code{scale} is \code{TRUE} then scaling is done by dividing the
>> - (centered) columns of \code{x} by their standard deviations, and if
>> + (centered) columns of \code{x} by their root-mean-squares, and if
>> \code{scale} is \code{FALSE}, no scaling is done.
>> -
>> - The standard deviation for a column is obtained by computing the
>> - square-root of the sum-of-squares of the non-missing values in the
>> - column divided by the number of non-missing values minus one (whether
>> - or not centering was done).
>> +
>> + The root-mean-square for a (possibly centered)
>> + column is defined as
>> + \eqn{\sqrt{\sum(x^2)/(n-1)}}{sqrt(sum(x^2)/(n-1))},
>> + where \eqn{x} is a vector of the non-missing values
>> + and \eqn{n} is the number of non-missing values.
>> + If (and only if) centering was done,
>> + this is equivalent to \code{sd(x,na.rm=TRUE)}.
>> + (To scale by the standard deviations without centering,
>> + use \code{scale(x,center=FALSE,scale=apply(x,2,sd,na.rm=TRUE))}.)
>> }
>> \references{
>> Becker, R. A., Chambers, J. M. and Wilks, A. R. (1988)
>>
>> (Bump re: suggested update to scale.Rd . Is this under
>> consideration? I'll stop pestering if it's considered
>> unacceptable, just don't want it to vanish without a trace ...)
>>
>>
>> --
>> Ben Bolker
>> Associate professor, Biology Dep't, Univ. of Florida
>> bol...@ufl.edu / people.biology.ufl.edu/bolker
>> GPG key: people.biology.ufl.edu/bolker/benbolker-publickey.asc
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Ben Bolker
Associate professor, Biology Dep't, Univ. of Florida
bol...@ufl.edu / people.biology.ufl.edu/bolker
GPG key: people.biology.ufl.edu/bolker/benbolker-publickey.asc
signature.asc
Description: OpenPGP digital signature
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
