Re: [Rd] apropos changes in r-devel: intended feature or bug?
> "DeepS" == Deepayan Sarkar <[EMAIL PROTECTED]>
> on Thu, 21 Dec 2006 22:07:27 -0800 writes:
DeepS> The old apropos started with: if
DeepS> (!is.character(what)) what <-
DeepS> as.character(substitute(what))
DeepS> The new one has:
DeepS>if (character.only) stopifnot(is.character(what))
DeepS>else what <- as.character(substitute(what))
DeepS> i.e., the check for is.character(what) is
DeepS> missing. This has the effect that 'what' can no
DeepS> longer be a character string generated by a function
DeepS> call unless 'character.only = TRUE'. I don't think
DeepS> this was intended; the change makes previously valid
DeepS> use invalid and I can't think of a situation where it
DeepS> is useful.
[ Did you read the corresponding NEWS entry? ]
It now parallelizes the use in library() , require() etc,
and in particular does what the documentation says it does!
The old behavior was much less consistent and not according to
documentation:
apropos(lm)was equivalent to apropos("lm")
but apropos(fit) gave an error.
Martin
DeepS> -Deepayan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] variable scope in update(): bug or feature?
Hi Michael, can you please - use a simple reproducible example -- just for the convenience of your readers - use R-help. This is really a question about R. > "Michael" == Michael <[EMAIL PROTECTED]> > on Thu, 21 Dec 2006 11:08:15 -0600 writes: Michael> I stumbled upon this when using update() Michael> (specifically update.lm()). If in the original Michael> call to lm(), say Michael> a <- lm (y ~ x + z, data = mydata) Michael> where y and z are in data frame mydata but x is in Michael> the global environment. Michael> Then if later I run, Michael> a0 <- update (a, ~ . - z) Michael> a0$model will contain values of x in the global Michael> environment which may well be different, even Michael> different length from mydata$y. Somehow, update() Michael> pads a0$model to have the same number of rows as Michael> the length of x. Michael> I would think that it would desirable to use x as Michael> in a$model rather than the global one. Michael> Is this a bug or a deliberate feature? Michael> Thanks, Michael> Michael Michael> __ Michael> R-devel@r-project.org mailing list Michael> https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] tiny typo in ?formals
Thanks! I took the opportunity to run aspell over all the help pages, so this turned into a few dozen small corrections. On Thu, 21 Dec 2006, Ben Bolker wrote: > > in 2.4.1: > > under Value, > > "The replacment [sic] form sets the formals of a function ..." > > -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] substitute creates an object which prints incorrectly (PR#9427)
The function "substitute" seems to fail to make a genuine
substitution, although the printed verision seems fine. Here is an
example.
> m <- substitute(Y <- function(x) FUN(x+1),
+ list(Y = as.name("y"), FUN = as.name("sin")))
> m
y <- function(x) sin(x + 1)
> eval(m)
> y
function(x) FUN(x+1)
However the story doesn't end there. The substitution appears to have
been made, even though the printed version, this time, suggests
otherwise.
> y(pi)
[1] -0.841471
> sin(pi+1)
[1] -0.841471
>
Bill Venables
CMIS, CSIRO Laboratories,
PO Box 120, Cleveland, Qld. 4163
AUSTRALIA
Office Phone (email preferred): +61 7 3826 7251
Fax (if absolutely necessary):+61 7 3826 7304
Mobile (rarely used):+61 4 1963 4642
Home Phone: +61 7 3286 7700
mailto:[EMAIL PROTECTED]
http://www.cmis.csiro.au/bill.venables/
--please do not edit the information below--
Version:
platform = i386-pc-mingw32
arch = i386
os = mingw32
system = i386, mingw32
status =
major = 2
minor = 4.1
year = 2006
month = 12
day = 18
svn rev = 40228
language = R
version.string = R version 2.4.1 (2006-12-18)
Windows XP Professional (build 2600) Service Pack 2.0
Locale:
LC_COLLATE=English_Australia.1252;LC_CTYPE=English_Australia.1252;LC_MON
ETARY=English_Australia.1252;LC_NUMERIC=C;LC_TIME=English_Australia.1252
Search Path:
.GlobalEnv, .R_Store, package:RODBC, package:xlsReadWrite,
package:cluster, package:vegan, package:ASOR, package:stats,
package:graphics, package:grDevices, package:utils, package:datasets,
.R_Data, .R_Utils, package:svIDE, package:tcltk, package:methods,
Autoloads, package:base
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] substitute creates an object which prints incorrectly (PR#9427)
[EMAIL PROTECTED] wrote:
> The function "substitute" seems to fail to make a genuine
> substitution, although the printed verision seems fine. Here is an
> example.
>
>
>> m <- substitute(Y <- function(x) FUN(x+1),
>>
> + list(Y = as.name("y"), FUN = as.name("sin")))
>
>> m
>>
> y <- function(x) sin(x + 1)
>
>> eval(m)
>> y
>>
> function(x) FUN(x+1)
>
> However the story doesn't end there. The substitution appears to have
> been made, even though the printed version, this time, suggests
> otherwise.
>
>
>> y(pi)
>>
> [1] -0.841471
>
>> sin(pi+1)
>>
> [1] -0.841471
>
>
>
Yes, this is (fairly) well known. It has to do with the retention of
function source.
The thing to notice is that it is only the printing of y that is really
confused. If you do
dput(y)
attr(y, "source")
attr(y, "source") <- NULL
y
then you should see the point. The tricky bit is that the "source"
attribute exists in an intermediate form inside m. Notice that m
contains, not the function itself, but a call to the function `function`
which creates the function when eval'ed. This call contains the function
source as its 4th element (look at m[[3]][[4]] in your example), and you
might try setting it to NULL and see how things will clear up.
The issue with substitute is that it cannot sensibly substitute into
character vectors, so it just leaves the source as is, which gives the
symptoms you see. It could, however, and probably should, recognize
calls to `function` and NULL out their 4th element. It cannot be done
completely failsafe though (`function` could result from a computation,
or even be part of the substitution), so one has to decide that the
extreme cases are too extreme worry about them.
-pd
> Bill Venables
> CMIS, CSIRO Laboratories,
> PO Box 120, Cleveland, Qld. 4163
> AUSTRALIA
> Office Phone (email preferred): +61 7 3826 7251
> Fax (if absolutely necessary):+61 7 3826 7304
> Mobile (rarely used):+61 4 1963 4642
> Home Phone: +61 7 3286 7700
> mailto:[EMAIL PROTECTED]
> http://www.cmis.csiro.au/bill.venables/
>
>
> --please do not edit the information below--
>
> Version:
> platform = i386-pc-mingw32
> arch = i386
> os = mingw32
> system = i386, mingw32
> status =
> major = 2
> minor = 4.1
> year = 2006
> month = 12
> day = 18
> svn rev = 40228
> language = R
> version.string = R version 2.4.1 (2006-12-18)
>
> Windows XP Professional (build 2600) Service Pack 2.0
>
> Locale:
> LC_COLLATE=English_Australia.1252;LC_CTYPE=English_Australia.1252;LC_MON
> ETARY=English_Australia.1252;LC_NUMERIC=C;LC_TIME=English_Australia.1252
>
> Search Path:
> .GlobalEnv, .R_Store, package:RODBC, package:xlsReadWrite,
> package:cluster, package:vegan, package:ASOR, package:stats,
> package:graphics, package:grDevices, package:utils, package:datasets,
> .R_Data, .R_Utils, package:svIDE, package:tcltk, package:methods,
> Autoloads, package:base
>
> __
> 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
Re: [Rd] substitute creates an object which prints incorrectly (PR#9427)
Try issuing the command:
options(keep.source = FALSE)
prior to running the code you displayed to force the actual source,
rather than the source attribute, to be displayed by print when printing
functions.
On 12/21/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> The function "substitute" seems to fail to make a genuine
> substitution, although the printed verision seems fine. Here is an
> example.
>
> > m <- substitute(Y <- function(x) FUN(x+1),
> + list(Y = as.name("y"), FUN = as.name("sin")))
> > m
> y <- function(x) sin(x + 1)
> > eval(m)
> > y
> function(x) FUN(x+1)
>
> However the story doesn't end there. The substitution appears to have
> been made, even though the printed version, this time, suggests
> otherwise.
>
> > y(pi)
> [1] -0.841471
> > sin(pi+1)
> [1] -0.841471
> >
>
> Bill Venables
> CMIS, CSIRO Laboratories,
> PO Box 120, Cleveland, Qld. 4163
> AUSTRALIA
> Office Phone (email preferred): +61 7 3826 7251
> Fax (if absolutely necessary):+61 7 3826 7304
> Mobile (rarely used):+61 4 1963 4642
> Home Phone: +61 7 3286 7700
> mailto:[EMAIL PROTECTED]
> http://www.cmis.csiro.au/bill.venables/
>
>
> --please do not edit the information below--
>
> Version:
> platform = i386-pc-mingw32
> arch = i386
> os = mingw32
> system = i386, mingw32
> status =
> major = 2
> minor = 4.1
> year = 2006
> month = 12
> day = 18
> svn rev = 40228
> language = R
> version.string = R version 2.4.1 (2006-12-18)
>
> Windows XP Professional (build 2600) Service Pack 2.0
>
> Locale:
> LC_COLLATE=English_Australia.1252;LC_CTYPE=English_Australia.1252;LC_MON
> ETARY=English_Australia.1252;LC_NUMERIC=C;LC_TIME=English_Australia.1252
>
> Search Path:
> .GlobalEnv, .R_Store, package:RODBC, package:xlsReadWrite,
> package:cluster, package:vegan, package:ASOR, package:stats,
> package:graphics, package:grDevices, package:utils, package:datasets,
> .R_Data, .R_Utils, package:svIDE, package:tcltk, package:methods,
> Autoloads, package:base
>
> __
> 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
Re: [Rd] apropos changes in r-devel: intended feature or bug?
> Martin Maechler writes:
> "DeepS" == Deepayan Sarkar <[EMAIL PROTECTED]>
> on Thu, 21 Dec 2006 22:07:27 -0800 writes:
DeepS> The old apropos started with: if
DeepS> (!is.character(what)) what <-
DeepS> as.character(substitute(what))
DeepS> The new one has:
DeepS> if (character.only) stopifnot(is.character(what))
DeepS> else what <- as.character(substitute(what))
DeepS> i.e., the check for is.character(what) is
DeepS> missing. This has the effect that 'what' can no
DeepS> longer be a character string generated by a function
DeepS> call unless 'character.only = TRUE'. I don't think
DeepS> this was intended; the change makes previously valid
DeepS> use invalid and I can't think of a situation where it
DeepS> is useful.
> [ Did you read the corresponding NEWS entry? ]
> It now parallelizes the use in library() , require() etc,
> and in particular does what the documentation says it does!
> The old behavior was much less consistent and not according to
> documentation:
> apropos(lm)was equivalent to apropos("lm")
> but apropos(fit) gave an error.
I would actually prefer if we only had standard evaluation for apropos()
and find().
(I understand we cannot do this for library() and help().)
-k
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] apropos changes in r-devel: intended feature or bug?
On Fri, 22 Dec 2006, Kurt Hornik wrote:
>> Martin Maechler writes:
>
>> "DeepS" == Deepayan Sarkar <[EMAIL PROTECTED]>
>> on Thu, 21 Dec 2006 22:07:27 -0800 writes:
>
> DeepS> The old apropos started with: if
> DeepS> (!is.character(what)) what <-
> DeepS> as.character(substitute(what))
>
> DeepS> The new one has:
>
> DeepS> if (character.only) stopifnot(is.character(what))
> DeepS> else what <- as.character(substitute(what))
>
> DeepS> i.e., the check for is.character(what) is
> DeepS> missing. This has the effect that 'what' can no
> DeepS> longer be a character string generated by a function
> DeepS> call unless 'character.only = TRUE'. I don't think
> DeepS> this was intended; the change makes previously valid
> DeepS> use invalid and I can't think of a situation where it
> DeepS> is useful.
>
>> [ Did you read the corresponding NEWS entry? ]
>
>> It now parallelizes the use in library() , require() etc,
>> and in particular does what the documentation says it does!
>
>> The old behavior was much less consistent and not according to
>> documentation:
>
>> apropos(lm)was equivalent to apropos("lm")
>> but apropos(fit) gave an error.
>
> I would actually prefer if we only had standard evaluation for apropos()
> and find().
>
> (I understand we cannot do this for library() and help().)
I agree completely. If it is OK to make changes that make previous
usage fail then it would be better to go to standard evaluation and
let apropos(lm) fail.
luke
--
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: [EMAIL PROTECTED]
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] apropos changes in r-devel: intended feature or bug?
Ok, so be it:
We have seen that both apropos() and find()
have used `some' non-standard evaluation up to R 2.4.1
which gave quite incosistent behavior.
Getting rid of non-standard evaluation get's rid of all
inconsistencies but of course is not back-compatible either.
I'll do this.
Martin
> "Luke" == Luke Tierney <[EMAIL PROTECTED]>
> on Fri, 22 Dec 2006 07:08:44 -0600 (CST) writes:
Luke> On Fri, 22 Dec 2006, Kurt Hornik wrote:
>>> Martin Maechler writes:
>>
>>> "DeepS" == Deepayan Sarkar <[EMAIL PROTECTED]>
>>> on Thu, 21 Dec 2006 22:07:27 -0800 writes:
>>
DeepS> The old apropos started with: if
DeepS> (!is.character(what)) what <-
DeepS> as.character(substitute(what))
>>
DeepS> The new one has:
>>
DeepS> if (character.only) stopifnot(is.character(what))
DeepS> else what <- as.character(substitute(what))
>>
DeepS> i.e., the check for is.character(what) is
DeepS> missing. This has the effect that 'what' can no
DeepS> longer be a character string generated by a function
DeepS> call unless 'character.only = TRUE'. I don't think
DeepS> this was intended; the change makes previously valid
DeepS> use invalid and I can't think of a situation where it
DeepS> is useful.
>>
>>> [ Did you read the corresponding NEWS entry? ]
>>
>>> It now parallelizes the use in library() , require() etc,
>>> and in particular does what the documentation says it does!
>>
>>> The old behavior was much less consistent and not according to
>>> documentation:
>>
>>> apropos(lm)was equivalent to apropos("lm")
>>> but apropos(fit) gave an error.
>>
>> I would actually prefer if we only had standard evaluation for apropos()
>> and find().
>>
>> (I understand we cannot do this for library() and help().)
Luke> I agree completely. If it is OK to make changes that make previous
Luke> usage fail then it would be better to go to standard evaluation and
Luke> let apropos(lm) fail.
Luke> luke
Luke> --
Luke> Luke Tierney
Luke> Chair, Statistics and Actuarial Science
Luke> Ralph E. Wareham Professor of Mathematical Sciences
Luke> University of Iowa Phone: 319-335-3386
Luke> Department of Statistics andFax: 319-335-3017
Luke> Actuarial Science
Luke> 241 Schaeffer Hall email: [EMAIL PROTECTED]
Luke> Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
Luke> __
Luke> R-devel@r-project.org mailing list
Luke> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] apropos changes in r-devel: intended feature or bug?
I have not been followin this thread but if apropos is changed note that
the
Help | Apropos
menu item in Windows may to be changed depending on what the
change is.
On 12/22/06, Martin Maechler <[EMAIL PROTECTED]> wrote:
> Ok, so be it:
>
> We have seen that both apropos() and find()
> have used `some' non-standard evaluation up to R 2.4.1
> which gave quite incosistent behavior.
>
> Getting rid of non-standard evaluation get's rid of all
> inconsistencies but of course is not back-compatible either.
>
> I'll do this.
> Martin
>
>
> > "Luke" == Luke Tierney <[EMAIL PROTECTED]>
> > on Fri, 22 Dec 2006 07:08:44 -0600 (CST) writes:
>
>Luke> On Fri, 22 Dec 2006, Kurt Hornik wrote:
>>>> Martin Maechler writes:
>>>
>>>> "DeepS" == Deepayan Sarkar <[EMAIL PROTECTED]>
>>>> on Thu, 21 Dec 2006 22:07:27 -0800 writes:
>>>
>DeepS> The old apropos started with: if
>DeepS> (!is.character(what)) what <-
>DeepS> as.character(substitute(what))
>>>
>DeepS> The new one has:
>>>
>DeepS> if (character.only) stopifnot(is.character(what))
>DeepS> else what <- as.character(substitute(what))
>>>
>DeepS> i.e., the check for is.character(what) is
>DeepS> missing. This has the effect that 'what' can no
>DeepS> longer be a character string generated by a function
>DeepS> call unless 'character.only = TRUE'. I don't think
>DeepS> this was intended; the change makes previously valid
>DeepS> use invalid and I can't think of a situation where it
>DeepS> is useful.
>>>
>>>> [ Did you read the corresponding NEWS entry? ]
>>>
>>>> It now parallelizes the use in library() , require() etc,
>>>> and in particular does what the documentation says it does!
>>>
>>>> The old behavior was much less consistent and not according to
>>>> documentation:
>>>
>>>> apropos(lm)was equivalent to apropos("lm")
>>>> but apropos(fit) gave an error.
>>>
>>> I would actually prefer if we only had standard evaluation for apropos()
>>> and find().
>>>
>>> (I understand we cannot do this for library() and help().)
>
>Luke> I agree completely. If it is OK to make changes that make previous
>Luke> usage fail then it would be better to go to standard evaluation and
>Luke> let apropos(lm) fail.
>
>Luke> luke
>
>Luke> --
>Luke> Luke Tierney
>Luke> Chair, Statistics and Actuarial Science
>Luke> Ralph E. Wareham Professor of Mathematical Sciences
>Luke> University of Iowa Phone: 319-335-3386
>Luke> Department of Statistics andFax: 319-335-3017
>Luke> Actuarial Science
>Luke> 241 Schaeffer Hall email: [EMAIL PROTECTED]
>Luke> Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
>
>Luke> __
>Luke> R-devel@r-project.org mailing list
>Luke> https://stat.ethz.ch/mailman/listinfo/r-devel
>
> __
> 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] Base R: applying min/max functions() to character string vectors (PR#9428)
Full_Name: Xiao Gang FAN
Version: 2.4.0
OS: Windows XP
Submission from: (NULL) (159.50.101.9)
Dear All,
This is not really a bug report, but rather a change wish to the Base R
behaviour
on some functions when applying them to character strings vectors/matrices.
Actually in R, we can do thinks like, the most naturally way in this the world:
> "a" < "b"
[1] TRUE
> order(c("b","a"))
[1] 2 1
> pmax(c("a","b"), c("b"))
[1] "b" "b"
But helas, we can't do things like:
> max(c("a","b"))
Error in max(..., na.rm = na.rm) : invalid 'type' (character) of argument
> range(c("z","b","w","c"))
Error in min(..., na.rm = na.rm) : invalid 'type' (character) of argument
> which.min(c("b","a"))
integer(0)
Warning message:
NAs introduced by coercion
I hope that you could understand the incoherence exhibited here
and my wish to see that to be changed some day, say in the becoming
year 2007. Here's a first list of functions to be reviewed:
min(), max(), which.min(), which.max(), range(), ...
Best regards and happy holidays to all of you !
--
Fan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Base R: applying min/max functions() to character string vectors (PR#9428)
On 12/22/2006 10:20 AM, [EMAIL PROTECTED] wrote:
> Full_Name: Xiao Gang FAN
> Version: 2.4.0
> OS: Windows XP
> Submission from: (NULL) (159.50.101.9)
>
>
> Dear All,
>
> This is not really a bug report, but rather a change wish to the Base R
> behaviour
> on some functions when applying them to character strings vectors/matrices.
>
> Actually in R, we can do thinks like, the most naturally way in this the
> world:
>> "a" < "b"
> [1] TRUE
>
>> order(c("b","a"))
> [1] 2 1
>
>> pmax(c("a","b"), c("b"))
> [1] "b" "b"
>
>
> But helas, we can't do things like:
>> max(c("a","b"))
> Error in max(..., na.rm = na.rm) : invalid 'type' (character) of argument
>
>> range(c("z","b","w","c"))
> Error in min(..., na.rm = na.rm) : invalid 'type' (character) of argument
>
>> which.min(c("b","a"))
> integer(0)
> Warning message:
> NAs introduced by coercion
>
> I hope that you could understand the incoherence exhibited here
> and my wish to see that to be changed some day, say in the becoming
> year 2007. Here's a first list of functions to be reviewed:
> min(), max(), which.min(), which.max(), range(), ...
That does seem like a reasonable change. Why not submit a patch? min
and max are in https://svn.r-project.org/R/trunk/src/main/summary.c. I
haven't looked up the others, but it's possible they just call the
internal code for min and max.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] variable scope in update(): bug or feature?
On 22 Dec 2006, Martin Maechler wrote: > - use a simple reproducible example -- > just for the convenience of your readers Sending email directly to r-devel doesn't seem to work for me. So I'm resend this via gmane. Here is an example: > rm (list = ls()) > x <- 1:10 > mdata <- data.frame (z = rnorm (10), y = x + 3) > m1 <- lm (y ~ x + z, data = mdata) > summary (m1) Call: lm(formula = y ~ x + z, data = mdata) Residuals: Min 1Q Median 3QMax -4.950e-16 -8.107e-17 2.085e-17 9.043e-17 3.787e-16 Coefficients: Estimate Std. Errort value Pr(>|t|) (Intercept) 3.000e+00 1.923e-16 1.560e+16 <2e-16 *** x1.000e+00 2.881e-17 3.472e+16 <2e-16 *** z -8.717e-17 1.149e-16 -7.590e-010.473 --- Signif. codes: 0 '***' 0.001 '**' 0.01 '*' 0.05 '.' 0.1 ' ' 1 Residual standard error: 2.6e-16 on 7 degrees of freedom Multiple R-Squared: 1, Adjusted R-squared: 1 F-statistic: 6.103e+32 on 2 and 7 DF, p-value: < 2.2e-16 > x <- rep (1:2, each = 5) > m2 <- update (m1, ~ . - z) > summary (m2) Call: lm(formula = y ~ x, data = mdata) Residuals: Min 1Q Median 3QMax -2.000e+00 -1.000e+00 2.086e-16 1.000e+00 2.000e+00 Coefficients: Estimate Std. Error t value Pr(>|t|) (Intercept)1.000 1.581 0.632 0.54474 x 5.000 1.000 5.000 0.00105 ** --- Signif. codes: 0 '***' 0.001 '**' 0.01 '*' 0.05 '.' 0.1 ' ' 1 Residual standard error: 1.581 on 8 degrees of freedom Multiple R-Squared: 0.7576, Adjusted R-squared: 0.7273 F-statistic:25 on 1 and 8 DF, p-value: 0.001053 This is R 2.4.1 on Mac OS X 10.4.8. > - use R-help. This is really a question about R. I think this could be a bug (at least it is not doing what I expected) so I emailed R-devel. Michael __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] apropos changes in r-devel: intended feature or bug?
On 12/22/06, Martin Maechler <[EMAIL PROTECTED]> wrote:
> > "DeepS" == Deepayan Sarkar <[EMAIL PROTECTED]>
> > on Thu, 21 Dec 2006 22:07:27 -0800 writes:
>
> DeepS> The old apropos started with: if
> DeepS> (!is.character(what)) what <-
> DeepS> as.character(substitute(what))
>
> DeepS> The new one has:
>
> DeepS>if (character.only) stopifnot(is.character(what))
> DeepS>else what <- as.character(substitute(what))
>
> DeepS> i.e., the check for is.character(what) is
> DeepS> missing. This has the effect that 'what' can no
> DeepS> longer be a character string generated by a function
> DeepS> call unless 'character.only = TRUE'. I don't think
> DeepS> this was intended; the change makes previously valid
> DeepS> use invalid and I can't think of a situation where it
> DeepS> is useful.
>
> [ Did you read the corresponding NEWS entry? ]
Yes, but I didn't connect all the dots. Anyway, I'm happy with either
option (my usage will have to modified anyway).
While we're on the topic of apropos, here's another question:it seems
that determining the mode of an object requires it to be loaded (and
evaluated), at least with the current 'exists' implementation. This
means that whenever 'mode' is not "any", all matching symbols are
loaded. So, something as innocuous looking as
apropos(".", mode = "logical")
will load every lazy-loaded symbol visible, even though very few
things match the mode:
[This is an older r-devel, 2006-11-29 r40062]
> system.time(print(apropos(".", mode = "logical")))
[1] ".noGenerics" "F" ".noGenerics" "T"
user system elapsed
0.640 0.008 0.648
## after loading a huge annotation package
> library(hgu133plus2)
> system.time(print(apropos(".", mode = "logical")))
[1] ".noGenerics" "F" ".noGenerics" "T"
user system elapsed
63.112 0.980 64.815
## repeating (now everything is loaded)
> system.time(print(apropos(".", mode = "logical")))
[1] ".noGenerics" "F" ".noGenerics" "T"
user system elapsed
0.144 0.000 0.143
Is there any hope of avoiding this loading? If not, it might be
helpful to put a note in one of the help pages.
-Deepayan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] variable scope in update(): bug or feature?
You haven't told us what you consider to be the bug here. Note that the help page for update says 'update' will update and (by default) re-fit a model. It does this by extracting the call stored in the object, updating the call and (by default) evaluating that call. Sometimes it is useful to call 'update' with only one argument, for example if the data frame has been corrected. which seems to be exactly in accord with the behaviour you report (especially the last sentence). Please tell us what you expected and where exactly it is documented that R works the way you expected. On Fri, 22 Dec 2006, Michael wrote: > > On 22 Dec 2006, Martin Maechler wrote: > >> - use a simple reproducible example -- >> just for the convenience of your readers > > Sending email directly to r-devel doesn't seem to work for me. So I'm > resend this via gmane. > > Here is an example: > >> rm (list = ls()) >> x <- 1:10 >> mdata <- data.frame (z = rnorm (10), y = x + 3) >> m1 <- lm (y ~ x + z, data = mdata) >> summary (m1) > > Call: > lm(formula = y ~ x + z, data = mdata) > > Residuals: > Min 1Q Median 3QMax > -4.950e-16 -8.107e-17 2.085e-17 9.043e-17 3.787e-16 > > Coefficients: > Estimate Std. Errort value Pr(>|t|) > (Intercept) 3.000e+00 1.923e-16 1.560e+16 <2e-16 *** > x1.000e+00 2.881e-17 3.472e+16 <2e-16 *** > z -8.717e-17 1.149e-16 -7.590e-010.473 > --- > Signif. codes: 0 '***' 0.001 '**' 0.01 '*' 0.05 '.' 0.1 ' ' 1 > > Residual standard error: 2.6e-16 on 7 degrees of freedom > Multiple R-Squared: 1, Adjusted R-squared: 1 > F-statistic: 6.103e+32 on 2 and 7 DF, p-value: < 2.2e-16 > >> x <- rep (1:2, each = 5) >> m2 <- update (m1, ~ . - z) >> summary (m2) > > Call: > lm(formula = y ~ x, data = mdata) > > Residuals: > Min 1Q Median 3QMax > -2.000e+00 -1.000e+00 2.086e-16 1.000e+00 2.000e+00 > > Coefficients: > Estimate Std. Error t value Pr(>|t|) > (Intercept)1.000 1.581 0.632 0.54474 > x 5.000 1.000 5.000 0.00105 ** > --- > Signif. codes: 0 '***' 0.001 '**' 0.01 '*' 0.05 '.' 0.1 ' ' 1 > > Residual standard error: 1.581 on 8 degrees of freedom > Multiple R-Squared: 0.7576, Adjusted R-squared: 0.7273 > F-statistic:25 on 1 and 8 DF, p-value: 0.001053 > > This is R 2.4.1 on Mac OS X 10.4.8. > >> - use R-help. This is really a question about R. > > I think this could be a bug (at least it is not doing what I expected) > so I emailed R-devel. > > Michael > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] variable scope in update(): bug or feature?
On 22 Dec 2006, Brian Ripley wrote: > 'update' will update and (by default) re-fit a model. It does this > by extracting the call stored in the object, updating the call and > (by default) evaluating that call. Sometimes it is useful to call > 'update' with only one argument, for example if the data frame has > been corrected. Thanks. I understand now that this is the expected behavior per the documentation. It is just that when I call 'update (m1, ~ . - z)' I did not expect x to change (or everything can be different if mydata has changed). I only wanted to evaluate the old model with old data but sans the z variable. Would it be useful to have an option in update() not to update the data (i.e., behaves more like drop1())? Michael __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] substitute creates an object which prints incorrectly (PR#9427)
Thanks Peter. I see the dilemma. It is serious in my view, though,
even if I can't see an elegant way round it.
I guess the only possibilities are
1. Only keep the source in printing or, much more seriously, dumping, if
the source attribute parses to an object structually identical to the
function itself (even I can see this is going to be impractical)
2. Make the default keep.source option FALSE rather than TRUE and warn
people that switching it on can be unsafe in language manipulation.
This would be practical, I suggest, if comments were kept as part of the
function itself, as well as in the source attribute, but if comments are
only kept in the source attribute (as appears to be the case now) I
concede this becomes impractical.
3. Modify substitute() so that it strips source attributes (or anything
else apparently visible that it will not manipulate) from objects.
Sorry folks, too dangerous. (I concede this appears to be a bit of an
overkill, too.)
Perhaps the compromise has to be to warn people that keep.source=TRUE
can be dangerous in this way, both in the help informaton for options()
and for substitute().
?
Bill Venables.
-Original Message-
From: Peter Dalgaard [mailto:[EMAIL PROTECTED]
Sent: Friday, 22 December 2006 9:47 PM
To: Venables, Bill (CMIS, Cleveland)
Cc: r-devel@stat.math.ethz.ch; [EMAIL PROTECTED]
Subject: Re: [Rd] substitute creates an object which prints incorrectly
(PR#9427)
[EMAIL PROTECTED] wrote:
> The function "substitute" seems to fail to make a genuine
> substitution, although the printed verision seems fine. Here is an
> example.
>
>
>> m <- substitute(Y <- function(x) FUN(x+1),
>>
> + list(Y = as.name("y"), FUN = as.name("sin")))
>
>> m
>>
> y <- function(x) sin(x + 1)
>
>> eval(m)
>> y
>>
> function(x) FUN(x+1)
>
> However the story doesn't end there. The substitution appears to have
> been made, even though the printed version, this time, suggests
> otherwise.
>
>
>> y(pi)
>>
> [1] -0.841471
>
>> sin(pi+1)
>>
> [1] -0.841471
>
>
>
Yes, this is (fairly) well known. It has to do with the retention of
function source.
The thing to notice is that it is only the printing of y that is really
confused. If you do
dput(y)
attr(y, "source")
attr(y, "source") <- NULL
y
then you should see the point. The tricky bit is that the "source"
attribute exists in an intermediate form inside m. Notice that m
contains, not the function itself, but a call to the function `function`
which creates the function when eval'ed. This call contains the function
source as its 4th element (look at m[[3]][[4]] in your example), and you
might try setting it to NULL and see how things will clear up.
The issue with substitute is that it cannot sensibly substitute into
character vectors, so it just leaves the source as is, which gives the
symptoms you see. It could, however, and probably should, recognize
calls to `function` and NULL out their 4th element. It cannot be done
completely failsafe though (`function` could result from a computation,
or even be part of the substitution), so one has to decide that the
extreme cases are too extreme worry about them.
-pd
> Bill Venables
> CMIS, CSIRO Laboratories,
> PO Box 120, Cleveland, Qld. 4163
> AUSTRALIA
> Office Phone (email preferred): +61 7 3826 7251
> Fax (if absolutely necessary):+61 7 3826 7304
> Mobile (rarely used):+61 4 1963 4642
> Home Phone: +61 7 3286 7700
> mailto:[EMAIL PROTECTED]
> http://www.cmis.csiro.au/bill.venables/
>
>
> --please do not edit the information below--
>
> Version:
> platform = i386-pc-mingw32
> arch = i386
> os = mingw32
> system = i386, mingw32
> status =
> major = 2
> minor = 4.1
> year = 2006
> month = 12
> day = 18
> svn rev = 40228
> language = R
> version.string = R version 2.4.1 (2006-12-18)
>
> Windows XP Professional (build 2600) Service Pack 2.0
>
> Locale:
>
LC_COLLATE=English_Australia.1252;LC_CTYPE=English_Australia.1252;LC_MON
>
ETARY=English_Australia.1252;LC_NUMERIC=C;LC_TIME=English_Australia.1252
>
> Search Path:
> .GlobalEnv, .R_Store, package:RODBC, package:xlsReadWrite,
> package:cluster, package:vegan, package:ASOR, package:stats,
> package:graphics, package:grDevices, package:utils, package:datasets,
> .R_Data, .R_Utils, package:svIDE, package:tcltk, package:methods,
> Autoloads, package:base
>
> __
> 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
