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
[Rd] Bug or feature?
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?
--
Sincerely
Andr� GILLIBERT
[[alternative HTML version deleted]]
__
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
Wow, that was fast! Thanks a lot!
Regards,
Janko
On 06.06.2011 18:29, John Chambers wrote:
> 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, minima
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
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
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 a
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?)
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
[Rd] Bug or feature: using "ANY" as a generic field class (was: '[R] Is there a (virtual) class that all R objects inherit from?)
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.
>>
>>
--
Computational Biology
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N. PO Box 19024 Seattle, WA 98109
Location: M1-B861
Telephone: 206 667-2793
[[alternative HTML version deleted]]
__
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 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?
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
[Rd] bug (or feature) in alpha 2.13?
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.
Norm Matloff
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] bug or feature in read.table?
Hi, I guess that the followig line in read.table tmp[i[i > 0L]] <- colClasses should read tmp[i[i > 0L]] <- colClasses[i > 0L] Is this a bug? Cheers Jens Oehlschlägel -- für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 __ 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
[Rd] Bug or Feature in Rcmd build workaround workaround for paths in Cygwin tar
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.
Best regards,
Michael Höhle
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
