Re: [Rd] Bug or feature?
> GILLIBERT, Andre
> on Sat, 14 Jan 2023 16:05:31 + writes:
> Dear developers,
> I found an inconsistency in the predict.lm() function between offset and
non-offset terms of the formula, but I am not sure whether that is intentional
or a bug.
> The problem can be shown in a simple example:
> mod <- local({
> y <- rep(0,10)
> x <- rep(c(0,1), each=5)
> list(lm(y ~ x), lm(y ~ offset(x)))
> })
> # works fine, using the x variable of the local environment
> predict(mod[[1]], newdata=data.frame(z=1:10))
> # error 'x' not found, because it seeks x in the global environment
> predict(mod[[2]], newdata=data.frame(z=1:10))
> I would expect either both predict() to use the local x
> variable or the global x variable, but the current
> behavior is inconsistent.
> In the worse case, both variables may exist but refer to
> different data, which seems to be very dangerous in my
> opinion.
> The problem becomes obvious from the source code of model.frame.default()
and predict.lm()
> predict.lm() calls model.frame()
> For a non-offset variable, the source code of model.frame.default shows:
> variables <- eval(predvars, data, env)
> Where env is the environment of the formula parameter.
> Consequently, non-offset variables are evaluated in the context of the
data frame, then in the environment of the formula/terms of the model.
> For offset variables, the source code of predict.lm() contains:
> eval(attr(tt, "variables")[[i + 1]], newdata)
> It is not executed in the environment of the formula/terms of the model.
> The inconsistency could easily be fixed by a patch to predict.lm() by
replacing eval(attr(tt, "variables")[[i + 1]], newdata) by eval(attr(tt,
"variables")[[i + 1]], newdata, environment(Terms))
> The same modification would have to be done two lines after:
> offset <- offset + eval(object$call$offset, newdata, environment(Terms))
> However, fixing this inconsistency could break code that rely on the old
behavior.
> What do you think of that?
As I've worked last week on the bugzilla issue about
predict.lm(), recently,
https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16158
and before that on another small detail there,
I indeed had noticed -- just from code reading --
that there seem to be several small inconsistencies in
predict.lm(); also, between the two branches se.fit=FALSE vs se.fit=TRUE
In the mean time, you have filed a new bugzilla isse about this,
https://bugs.r-project.org/show_bug.cgi?id=18456
so we (and everyone interested) will continue the discussion
there.
Thank you for contributing to make R better by this!
Best regards,
Martin
> --
> Sincerely
> Andr� GILLIBERT
--
Martin Maechler
ETH Zurich and R Core team
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bug or feature: using ANY as a generic field class (was: '[R] Is there a (virtual) class that all R objects inherit from?)
Thanks a lot for your reply and I'm sorry if I didn't make it quite clear what I expected, but you got it right: I'd simply like to see the same behavior for Reference Classes as for S4 classes when extending classes with ANY fields as featured in the example below. setClass(A, representation(x=ANY)) [1] A setClass(B, contains=A, representation(x=character)) [1] B new(B, x = abc) An object of class B Slot x: [1] abc Thanks for addressing this! Regards, Janko On 03.06.2011 19:13, John Chambers wrote: Well, your mail is unclear as to what you expected, but there is one bug shown by your example. The behavior of S4 classes is sensible, at least as far as the example shows: setClass(A, representation(x=ANY)) [1] A setClass(B, contains=A, representation(x=character)) [1] B new(B, x=1:3) Error in validObject(.Object) : invalid class B object: invalid object for slot x in class B: got class integer, should be or extend class character You couldn't expect the new() call to work, as the error message clearly explains. A legitimate call does work: new(B, x = abc) An object of class B Slot x: [1] abc The reference classes should work the same way, but don't, as your example shows. A - setRefClass( + Class=A, + fields=list( + .PRIMARYDATA=ANY + ), + contains=c(VIRTUAL) + ) B - setRefClass( + Class=B, + fields=list( + .PRIMARYDATA=character + ), + contains=c(A) + ) Error in `insertFields-`(`*tmp*`, value = character) : The overriding class(character) of field .PRIMARYDATA is not a subclass of the existing field definition (ANY) We'll fix that. And, yes, ANY is intended as a universal superclass, but is usually not mentioned explicitly. On 6/3/11 6:53 AM, Janko Thyson wrote: Dear list, I was wondering if you could help me out in clarifying something: Is it possible to use class ANY in slots/fields of formal classes if you a) do not want to restrict valid classes of that field and b) if you are making explicit use of class inheritance? It seems to work in simple scenarios but produces errors when class inheritance comes into play. So I was wondering if that's a feature or a bug. If using ANY is not the right way, I'd appreciate a pointer to how you can to this. See previous post with an example below. Regards, Janko On 06/03/2011 01:53 AM, Janko Thyson wrote: On 31.05.2011 18:17, Martin Morgan wrote: On 05/30/2011 07:02 AM, Janko Thyson wrote: Dear list, I would like to set one specific Reference Class field to be of an arbitrary class. Is there a class that all R objects inherit from? I thought that ANY was something like this, but obviously that's not true: inherits(1:3, ANY) [1] FALSE I can't speak to the implementation, but ANY functions as a base class in terms of slot / field assignment and inheritance, e.g., setClass(A, representation(x=ANY)) new(A, x=1:3) Martin Hi Martin, sorry for the late response. The way you do it works. Yet, when you declare dependencies more explicitly (contains=XY), then R complains. Is this a feature or a bug (with respect to the less explicit way working just fine)? See the example below: # S4 setClass(A, representation(x=ANY)) new(A, x=1:3) setClass(A, representation(x=ANY)) setClass(B, contains=A, representation(x=character)) new(B, x=1:3) # Reference Classes setRefClass( Class=A, fields=list( .PRIMARYDATA=ANY ), contains=c(VIRTUAL) ) B- setRefClass( Class=B, fields=list( .PRIMARYDATA=character ), contains=c(A) ) Bug, I'd say. Martin Regards, Janko Regards, Janko [[alternative HTML version deleted]] __ r-h...@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code. __ 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] Bug or feature: using ANY as a generic field class (was: '[R] Is there a (virtual) class that all R objects inherit from?)
Should now behave as expected in r-devel and 2.13 patched, as of SVN 56045, June 4. (noted in the NEWS file.) On 6/6/11 6:27 AM, Janko Thyson wrote: Thanks a lot for your reply and I'm sorry if I didn't make it quite clear what I expected, but you got it right: I'd simply like to see the same behavior for Reference Classes as for S4 classes when extending classes with ANY fields as featured in the example below. setClass(A, representation(x=ANY)) [1] A setClass(B, contains=A, representation(x=character)) [1] B new(B, x = abc) An object of class B Slot x: [1] abc Thanks for addressing this! Regards, Janko On 03.06.2011 19:13, John Chambers wrote: Well, your mail is unclear as to what you expected, but there is one bug shown by your example. The behavior of S4 classes is sensible, at least as far as the example shows: setClass(A, representation(x=ANY)) [1] A setClass(B, contains=A, representation(x=character)) [1] B new(B, x=1:3) Error in validObject(.Object) : invalid class B object: invalid object for slot x in class B: got class integer, should be or extend class character You couldn't expect the new() call to work, as the error message clearly explains. A legitimate call does work: new(B, x = abc) An object of class B Slot x: [1] abc The reference classes should work the same way, but don't, as your example shows. A - setRefClass( + Class=A, + fields=list( + .PRIMARYDATA=ANY + ), + contains=c(VIRTUAL) + ) B - setRefClass( + Class=B, + fields=list( + .PRIMARYDATA=character + ), + contains=c(A) + ) Error in `insertFields-`(`*tmp*`, value = character) : The overriding class(character) of field .PRIMARYDATA is not a subclass of the existing field definition (ANY) We'll fix that. And, yes, ANY is intended as a universal superclass, but is usually not mentioned explicitly. On 6/3/11 6:53 AM, Janko Thyson wrote: Dear list, I was wondering if you could help me out in clarifying something: Is it possible to use class ANY in slots/fields of formal classes if you a) do not want to restrict valid classes of that field and b) if you are making explicit use of class inheritance? It seems to work in simple scenarios but produces errors when class inheritance comes into play. So I was wondering if that's a feature or a bug. If using ANY is not the right way, I'd appreciate a pointer to how you can to this. See previous post with an example below. Regards, Janko On 06/03/2011 01:53 AM, Janko Thyson wrote: On 31.05.2011 18:17, Martin Morgan wrote: On 05/30/2011 07:02 AM, Janko Thyson wrote: Dear list, I would like to set one specific Reference Class field to be of an arbitrary class. Is there a class that all R objects inherit from? I thought that ANY was something like this, but obviously that's not true: inherits(1:3, ANY) [1] FALSE I can't speak to the implementation, but ANY functions as a base class in terms of slot / field assignment and inheritance, e.g., setClass(A, representation(x=ANY)) new(A, x=1:3) Martin Hi Martin, sorry for the late response. The way you do it works. Yet, when you declare dependencies more explicitly (contains=XY), then R complains. Is this a feature or a bug (with respect to the less explicit way working just fine)? See the example below: # S4 setClass(A, representation(x=ANY)) new(A, x=1:3) setClass(A, representation(x=ANY)) setClass(B, contains=A, representation(x=character)) new(B, x=1:3) # Reference Classes setRefClass( Class=A, fields=list( .PRIMARYDATA=ANY ), contains=c(VIRTUAL) ) B- setRefClass( Class=B, fields=list( .PRIMARYDATA=character ), contains=c(A) ) Bug, I'd say. Martin Regards, Janko Regards, Janko [[alternative HTML version deleted]] __ r-h...@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- *Janko Thyson* janko.thy...@ku-eichstaett.de mailto:janko.thy...@ku-eichstaett.de Catholic University of Eichstätt-Ingolstadt Ingolstadt School of Management Statistics and Quantitative Methods Auf der Schanz 49 D-85049 Ingolstadt www.wfi.edu/lsqm http://www.wfi.edu/lsqm Fon: +49 841 937-1923 Fax: +49 841 937-1965 This e-mail and any attachment is for authorized use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. __ R-devel@r-project.org mailing list
Re: [Rd] Bug or feature: using ANY as a generic field class (was: '[R] Is there a (virtual) class that all R objects inherit from?)
Well, your mail is unclear as to what you expected, but there is one bug shown by your example. The behavior of S4 classes is sensible, at least as far as the example shows: setClass(A, representation(x=ANY)) [1] A setClass(B, contains=A, representation(x=character)) [1] B new(B, x=1:3) Error in validObject(.Object) : invalid class B object: invalid object for slot x in class B: got class integer, should be or extend class character You couldn't expect the new() call to work, as the error message clearly explains. A legitimate call does work: new(B, x = abc) An object of class B Slot x: [1] abc The reference classes should work the same way, but don't, as your example shows. A - setRefClass( + Class=A, + fields=list( + .PRIMARYDATA=ANY + ), + contains=c(VIRTUAL) + ) B - setRefClass( + Class=B, + fields=list( + .PRIMARYDATA=character + ), + contains=c(A) + ) Error in `insertFields-`(`*tmp*`, value = character) : The overriding class(character) of field .PRIMARYDATA is not a subclass of the existing field definition (ANY) We'll fix that. And, yes, ANY is intended as a universal superclass, but is usually not mentioned explicitly. On 6/3/11 6:53 AM, Janko Thyson wrote: Dear list, I was wondering if you could help me out in clarifying something: Is it possible to use class ANY in slots/fields of formal classes if you a) do not want to restrict valid classes of that field and b) if you are making explicit use of class inheritance? It seems to work in simple scenarios but produces errors when class inheritance comes into play. So I was wondering if that's a feature or a bug. If using ANY is not the right way, I'd appreciate a pointer to how you can to this. See previous post with an example below. Regards, Janko On 06/03/2011 01:53 AM, Janko Thyson wrote: On 31.05.2011 18:17, Martin Morgan wrote: On 05/30/2011 07:02 AM, Janko Thyson wrote: Dear list, I would like to set one specific Reference Class field to be of an arbitrary class. Is there a class that all R objects inherit from? I thought that ANY was something like this, but obviously that's not true: inherits(1:3, ANY) [1] FALSE I can't speak to the implementation, but ANY functions as a base class in terms of slot / field assignment and inheritance, e.g., setClass(A, representation(x=ANY)) new(A, x=1:3) Martin Hi Martin, sorry for the late response. The way you do it works. Yet, when you declare dependencies more explicitly (contains=XY), then R complains. Is this a feature or a bug (with respect to the less explicit way working just fine)? See the example below: # S4 setClass(A, representation(x=ANY)) new(A, x=1:3) setClass(A, representation(x=ANY)) setClass(B, contains=A, representation(x=character)) new(B, x=1:3) # Reference Classes setRefClass( Class=A, fields=list( .PRIMARYDATA=ANY ), contains=c(VIRTUAL) ) B- setRefClass( Class=B, fields=list( .PRIMARYDATA=character ), contains=c(A) ) Bug, I'd say. Martin Regards, Janko Regards, Janko [[alternative HTML version deleted]] __ r-h...@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] bug (or feature) in alpha 2.13?
On 11-03-26 7:41 PM, Norm Matloff wrote: The pattern (I can make a simple example if needed): source(x.R) options(error=recover) x- ... f(x) # f() from x.R (subscript bounds error, now in recover()) Selection: 1 Browse[1] where In the output from where, there should be information on the line number at which the user code blew up. It's there in 2.12, but not in 2.13, from what I can see. That's not intentional. I'll see what went wrong... Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] bug (or feature) in alpha 2.13?
On 11-03-27 7:42 AM, Duncan Murdoch wrote:
On 11-03-26 7:41 PM, Norm Matloff wrote:
The pattern (I can make a simple example if needed):
source(x.R)
options(error=recover)
x- ...
f(x) # f() from x.R
(subscript bounds error, now in recover())
Selection: 1
Browse[1] where
In the output from where, there should be information on the line
number at which the user code blew up. It's there in 2.12, but not in
2.13, from what I can see.
That's not intentional. I'll see what went wrong...
Duncan Murdoch
Fixed now. Because of the internal change to srcref records
\item \code{srcref} attributes now include two additional
line number values, recording the line numbers in the order they
were parsed.
the code that saved the current location didn't recognize the record,
and skipped saving it.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] bug (or feature) in alpha 2.13?
Thanks very much, Duncan.
Norm
On Sun, Mar 27, 2011 at 08:57:08AM -0400, Duncan Murdoch wrote:
Fixed now. Because of the internal change to srcref records
\item \code{srcref} attributes now include two additional
line number values, recording the line numbers in the order they
were parsed.
the code that saved the current location didn't recognize the record,
and skipped saving it.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bug or Feature in Rcmd build workaround workaround for paths in Cygwin tar
On Mon, 6 Mar 2006, Michael Hoehle wrote:
To R-devel,
I am currently writing a package with R 2.2.1 under Windows using
cygwin and the recommended Rtools. Physically my package ist hosted on
the Drive z: .
When I call Rcmd.exe build ?-binary for my package I have a problem
with the build script in $R_HOME/bin/. Starting on line 226 the code
is as follows:
if($WINDOWS) {
## workaround for paths in Cygwin tar
$filepath =~ s+^([A-Za-x]):+/cygdrive/\1+;
}
Is there a particular reason that only lower case letter from a-x are
handled? As my drive is z: I would like the workaround to work for
lower case letters a-z.
So edit the file and it should work. (Something is a little strange, as
Windows has drive letters in upper case.)
You may need to edit check as well as build.
--
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
