Re: [Rd] S4 method dispatch
Thanks, John!
I did not manage to figure out how the strict= works, but changed class
inheritance such that simple inheritance did not take place.
I see you're advocating to use the contains= to stress inheritance; back
in 2005, I followed the green book, which did not yet have this.
If I now would change class definitions from using the representation=
into contains= to express inheritance, does the binary representation
also change, i.e. do people relying on sp classes get into problem with
old, saved objects read by the new software? I'm asking this because
there's lots of it around, e.g. all the world administrative regions
available as .RData files from http://gadm.org/ .
On 09/18/2011 11:04 PM, John Chambers wrote:
The distinction here is "simple inheritance" ("Software for Data
Analysis", p. 346). Your first example is simple inheritance (would be
clearer if you used the contains= argument). In the second version you
supply an explicit coerce method, so method dispatch can no longer just
pass in the object from the subclass, but has to call the coerce method
explicitly. Details in the reference.
If you need to have an explicit coerce method, it's possible to emulate
simple inheritance, but the programming may be more subtle than you want
to take on. When your method is called, it actually gets also an
argument strict= which will be FALSE for method dispatch. You need to
take account of the strict= argument in writing your method. See ?setAs
for a few more details. Someone on the list may have an example.
John
On 9/18/11 3:33 AM, Edzer Pebesma wrote:
As a follow-up, I managed to isolate the problem I sent earlier this
week, and reduced it to a small case (I'm using R 2.13.1,
i486-pc-linux-gnu (32-bit)).
The following script does what I expect:
setClass("A", representation(x = "numeric"))
setClass("AB", representation("A"))
setGeneric("doNothing<-", function(obj, value)
standardGeneric("doNothing<-"))
setReplaceMethod("doNothing", c("A", "character"),
function(obj, value) obj)
x = new("AB", x = 10)
doNothing(x) = "irrelevant"
class(x)
setAs("AB", "A", function(from) new("A", x = from@x))
x = new("AB", x = 10)
doNothing(x) = "irrelevant"
class(x)
and results in class(x) being "AB".
However, the following, very similar script:
setClass("A", representation(x = "numeric"))
setClass("AB", representation("A"))
setGeneric("doNothing<-", function(obj, value)
standardGeneric("doNothing<-"))
setReplaceMethod("doNothing", c("A", "character"),
function(obj, value) obj)
setAs("AB", "A", function(from) new("A", x = from@x))
x = new("AB", x = 10)
doNothing(x) = "irrelevant"
class(x)
returns "A" as the class of x. Why is this the case? Is this behaviour
intentional?
Best regards,
On 09/14/2011 11:00 PM, Edzer Pebesma wrote:
List,
In order to get rid of some old, unreadable S3 code in package sp, I'm
trying to rewrite things using S4 methods. Somewhere I fail, and I
cannot sort out why. In order to isolate the problem, I created two
functions, doNothing<- and dosth, and both should do nothing. The issue
is that in most cases they do nothing, but in some cases dosth(obj)
changes the class of obj and breaks with the error. I couldn't find a
pattern when this happens, but have a few cases where it consistently
breaks. Here's the code snippet:
setGeneric("doNothing<-", function(object, value)
standardGeneric("doNothing<-"))
setReplaceMethod("doNothing",
signature(object = "Spatial", value = "ANY"),
function(object, value) object)
dosth = function(obj) {
cl1 = class(obj)
doNothing(obj) = TRUE
cl2 = class(obj)
if (!identical(cl1, cl2)) {
print(paste(cl1, cl2))
stopifnot(identical(cl1, cl2))
}
obj
}
When things go wrong, dosth and doNothing are called with a subclass of
Spatial, e.g. an object of class SpatialGrid, but when this gets in
doNothing, the object is suddenly of class Spatial, and is then returned
as an object of class Spatial, which should never happen.
For instance, I have a case where consistently
setMethod("fullgrid", c("Spatial"),
function(obj) { is(obj, "SpatialGrid") })
class(g)
[1] "SpatialGrid"
attr(,"package")
[1] "sp"
fullgrid(g)
[1] FALSE
is obviously false, but in other cases it works fine.
When I change the signature of doNothing to signature(object = "ANY",
value = "ANY"), the problem disappears.
I tried to make a self-contained example that reproduced the issue, but
could only get something that worked as expected.
I would appreciate any help or suggestions.
--
Edzer Pebesma
Institute for Geoinformatics (ifgi), University of Münster
Weseler Straße 253, 48151 Münster, Germany. Phone: +49 251
8333081, Fax: +49 251 8339763 http://ifgi.uni-muenster.de
http://www.52north.org/geostatistics e.pebe...@wwu.de
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Warning: changing locked binding for ...
On Fri, 30 Sep 2011, Wincent wrote: Duncan, thanks very much. Yet, I don't recall I attempt to change any thing in the gWidgetsRGtk2. Is there a way to trace what part of the code is trying to do so? Use options(warn=2) I get library(RQDA) Loading required package: DBI Loading required package: RSQLite Loading required package: gWidgets Loading required package: gWidgetsRGtk2 Xlib: extension "RANDR" missing on display ":5.0". Use 'RQDA()' to start the programe. Select a GUI toolkit 1: gWidgetsRGtk2 2: gWidgetstcltk Selection: 1 Error : .onAttach failed in attachNamespace() for 'RQDA', details: call: NULL error: (converted from warning) changing locked binding for ‘stockIcons’ in ‘gWidgetsRGtk2’ whilst loading ‘RQDA’ Error: package/namespace load failed for ‘RQDA’ So take a closer look at your .onAttach. In fact it is gWidgetsRGtk2 that is using assignInNamespace, and you are running that in your startup code. assignInNamespace was never intended to be used in production code, and John Verzani's packages need to be re-designed to respect the integrity of their namespaces. Startup hooks was also not designed to be used to run large chunks of code, and as they are run under tryCatch they can be difficult to debug. Thanks. Wincent On 30 September 2011 01:01, Duncan Murdoch wrote: On 29/09/2011 12:44 PM, Wincent wrote: Dear all, I use the R R Under development (unstable) (2011-09-28 r57099). When I load the RQDA package, it issues warnings. As the RQDA package developer, what should I deal with such message? Thank you very much. Don't attempt to change variables in other packages. Something that RQDA is doing is attempting to change stockIcons and updateStockIcons in the gWidgetsRGtk2 package. Duncan Murdoch library(gWidgetsRGtk2) Loading required package: gWidgets library(RQDA) Loading required package: DBI Loading required package: RSQLite Use 'RQDA()' to start the programe. Warning: changing locked binding for ‘stockIcons’ in ‘gWidgetsRGtk2’ whilst loading ‘RQDA’ Warning: changing locked binding for ‘updateStockIcons’ in ‘gWidgetsRGtk2’ whilst loading ‘RQDA’ Warning: changing locked binding for ‘n’ in ‘gWidgets’ whilst loading ‘RQDA’ sessionInfo() R Under development (unstable) (2011-09-28 r57099) Platform: i386-pc-mingw32/i386 (32-bit) locale: [1] LC_COLLATE=Chinese (Simplified)_People's Republic of China.936 LC_CTYPE=Chinese (Simplified)_People's Republic of China.936 [3] LC_MONETARY=Chinese (Simplified)_People's Republic of China.936 LC_NUMERIC=C [5] LC_TIME=Chinese (Simplified)_People's Republic of China.936 attached base packages: [1] stats graphics grDevices utils datasets methods base other attached packages: [1] RQDA_0.2-1 RSQLite_0.9-4 DBI_0.2-5 gWidgetsRGtk2_0.0-76 gWidgets_0.0-46 loaded via a namespace (and not attached): [1] RGtk2_2.20.17 tools_2.14.0 -- Wincent Ronggui HUANG Sociology Department of Fudan University PhD of City University of Hong Kong http://homepage.fudan.edu.cn/rghuang/cv/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Brian D. Ripley, rip...@stats.ox.ac.uk 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] Finding inter-function dependencies within a package
Thanks for the suggestions. Just to wrap up this thread...
Rainer Krug pointed out that Roxygen did have dependency graphs, although
Roxygen2 doesn't. But I guess (probably wrongly!) that I'd need to
process/modify the .R files to use that, and I'm not the package author.
Duncan Murdoch pointed out codetools::findGlobals which can be used to find
functions called by a target function. But I want to find functions calling
a target function.
Mark Bravington pointed out mvbutils::foodweb and callers.of which almost do
what I want (I think it was this I half remembered). But this works in the
namespace of the package, and my target function isn't exported so foodweb
doesn't see it!
Working from Duncan's suggestion I came up with this, not pretty or fast,
could certainly be improved, but it did my one-off job.:
# return a character vector of names of functions in 'tarPack' (character)
which directly call the function 'tarFunc' (character)
called.by <- function(tarFunc, tarPack){
require(codetools)
flist <- sapply(lsf.str(tarPack, all=TRUE), c)
names(flist) <- NULL
gotit <- sapply(flist, function(x) tarFunc %in% findGlobals(get(x, tarPack),
FALSE)$functions)
flist[gotit]
}
# e.g.
called.by("CreateMeanFizz", "package:sensory")
--
Thanks again for the input.
Keith Jewell
>> Hi,
>>
>> I'd like to know which functions in a package call one specific
>> function.
>> I think I've seen a tool for identifying such dependencies, but now I
>> can't find it :-( Searches of help and R site search for keywords
>> like function, call, tree, depend haven't helped :-(
>>
>> Can anyone point me in the right direction?
>>
>> Thanks in advance,
>>
>> Keith Jewell
>>
>> __
>> 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] documenting a behavior of adding named item to a list
Folks, Per a post to StackOverflow, I'm looking for an opinion on whether something should be documented: When adding a named item to a list, its guaranteed that the item will be added to the end of the list. SO post: http://stackoverflow.com/questions/7599349/adding-named-item-to-list-guaranteed-to-append-to-end-of-list/7599610#7599610 This is my first email to r-devel, so I hope this is an appropriate question. -Suraj [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] documenting a behavior of adding named item to a list
On 29/09/2011 11:42 AM, Suraj Gupta wrote: Folks, Per a post to StackOverflow, I'm looking for an opinion on whether something should be documented: When adding a named item to a list, its guaranteed that the item will be added to the end of the list. I'd say not. There's an easy way to guarantee the order: instead of using mylist$newname <- 1 use mylist <- c(mylist, newname=1) The former construction doesn't necessarily put it last, only when newname is a new name. The latter guarantees that it goes last. Currently, you can do something like this: x <- list(1) # one element list x[[10]] <- 10 # grows x to a 10 element list, filling in NULLs in positions 2 to 9 x$newname <- 11 # puts the newname in the 11th position It's not obvious to me that the newname shouldn't go into the 2nd position (if I ignore the comments). I wouldn't want to rule that out as a future change. Duncan Murdoch SO post: http://stackoverflow.com/questions/7599349/adding-named-item-to-list-guaranteed-to-append-to-end-of-list/7599610#7599610 This is my first email to r-devel, so I hope this is an appropriate question. -Suraj [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] grep and PCRE fun
Jeff,
this is really a bug in PCRE since the length (0) is a multiple of 3 as
documented so PCRE should not be writing anything. Anyway, this has been now
fixed (by Brian).
Cheers,
Simon
On Sep 29, 2011, at 5:00 PM, Jeffrey Horner wrote:
> Hello,
>
> I think I've found a bug in the C function do_grep located in
> src/main/grep.c. It seems to affect both the latest revisions of
> R-2-13-branch and trunk when compiling R without optimizations and
> with it's own version of pcre located in src/extra, at least on ubuntu
> 10.04.
>
> According to the pcre_exec API (I presume the later versions), the
> ovecsize argument must be a multiple of 3 , and the ovector argument
> must point to a location that can hold at least ovecsize integers. All
> the pcre_exec calls made by do_grep, save one, honors this. That one
> call seems to overwrite areas of the stack it shouldn't. Here's the
> smallest example I found that tickles the bug:
>
>> grep("[^[:blank][:cntrl]]","\\n",perl=TRUE)
> Error in grep("[^[:blank][:cntrl]]", "\\n", perl = TRUE) :
> negative length vectors are not allowed
>
> As described above, this error occurs on ubuntu 10.04 when R is
> compiled without optimizations ( I typically use CFLAGS="-ggdb"
> CXXFLAGS="-ggdb" FFLAGS="-ggdb" ./configure --enable-R-shlib), and the
> pcre_exec call executed from do_get overwrites the integer nmatches
> and sets it to -1. This has the effect of making do_grep try and
> allocate a results vector of length -1, which of course causes the
> error message above.
>
> I'd be interested to know if this bug happens on other platforms.
>
> Below is my simple fix for R-2-13-branch (a similar fix works for
> trunk as well).
>
> Jeff
>
> $ svn diff main/grep.c
> Index: main/grep.c
> ===
> --- main/grep.c (revision 57110)
> +++ main/grep.c (working copy)
> @@ -723,7 +723,7 @@
> {
> SEXP pat, text, ind, ans;
> regex_t reg;
> -int i, j, n, nmatches = 0, ov, rc;
> +int i, j, n, nmatches = 0, ov[3], rc;
> int igcase_opt, value_opt, perl_opt, fixed_opt, useBytes, invert;
> const char *spat = NULL;
> pcre *re_pcre = NULL /* -Wall */;
> @@ -882,7 +882,7 @@
> if (fixed_opt)
> LOGICAL(ind)[i] = fgrep_one(spat, s, useBytes, use_UTF8, NULL)
> >= 0;
> else if (perl_opt) {
> - if (pcre_exec(re_pcre, re_pe, s, strlen(s), 0, 0, &ov, 0) >= 0)
> + if (pcre_exec(re_pcre, re_pe, s, strlen(s), 0, 0, ov, 3) >= 0)
> INTEGER(ind)[i] = 1;
> } else {
> if (!use_WC)
>
> __
> 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] grep and PCRE fun
On Fri, 30 Sep 2011, Simon Urbanek wrote:
Jeff,
this is really a bug in PCRE since the length (0) is a multiple of 3 as
documented so PCRE should not be writing anything. Anyway, this has been now
fixed (by Brian).
Only in R-devel: R-2-13-branch is now closed (and was by the time I
read the message).
Cheers,
Simon
On Sep 29, 2011, at 5:00 PM, Jeffrey Horner wrote:
Hello,
I think I've found a bug in the C function do_grep located in
src/main/grep.c. It seems to affect both the latest revisions of
R-2-13-branch and trunk when compiling R without optimizations and
with it's own version of pcre located in src/extra, at least on ubuntu
10.04.
According to the pcre_exec API (I presume the later versions), the
ovecsize argument must be a multiple of 3 , and the ovector argument
must point to a location that can hold at least ovecsize integers. All
the pcre_exec calls made by do_grep, save one, honors this. That one
call seems to overwrite areas of the stack it shouldn't. Here's the
smallest example I found that tickles the bug:
grep("[^[:blank][:cntrl]]","\\n",perl=TRUE)
Error in grep("[^[:blank][:cntrl]]", "\\n", perl = TRUE) :
negative length vectors are not allowed
As described above, this error occurs on ubuntu 10.04 when R is
compiled without optimizations ( I typically use CFLAGS="-ggdb"
CXXFLAGS="-ggdb" FFLAGS="-ggdb" ./configure --enable-R-shlib), and the
pcre_exec call executed from do_get overwrites the integer nmatches
and sets it to -1. This has the effect of making do_grep try and
allocate a results vector of length -1, which of course causes the
error message above.
I'd be interested to know if this bug happens on other platforms.
Below is my simple fix for R-2-13-branch (a similar fix works for
trunk as well).
Jeff
$ svn diff main/grep.c
Index: main/grep.c
===
--- main/grep.c (revision 57110)
+++ main/grep.c (working copy)
@@ -723,7 +723,7 @@
{
SEXP pat, text, ind, ans;
regex_t reg;
-int i, j, n, nmatches = 0, ov, rc;
+int i, j, n, nmatches = 0, ov[3], rc;
int igcase_opt, value_opt, perl_opt, fixed_opt, useBytes, invert;
const char *spat = NULL;
pcre *re_pcre = NULL /* -Wall */;
@@ -882,7 +882,7 @@
if (fixed_opt)
LOGICAL(ind)[i] = fgrep_one(spat, s, useBytes, use_UTF8, NULL)
>= 0;
else if (perl_opt) {
- if (pcre_exec(re_pcre, re_pe, s, strlen(s), 0, 0, &ov, 0) >= 0)
+ if (pcre_exec(re_pcre, re_pe, s, strlen(s), 0, 0, ov, 3) >= 0)
INTEGER(ind)[i] = 1;
} else {
if (!use_WC)
__
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
--
Brian D. Ripley, rip...@stats.ox.ac.uk
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] S4 method dispatch
On 9/30/11 12:48 AM, Edzer Pebesma wrote:
Thanks, John!
I did not manage to figure out how the strict= works, but changed class
inheritance such that simple inheritance did not take place.
I see you're advocating to use the contains= to stress inheritance; back
in 2005, I followed the green book, which did not yet have this.
If I now would change class definitions from using the representation=
into contains= to express inheritance, does the binary representation
also change, i.e. do people relying on sp classes get into problem with
old, saved objects read by the new software? I'm asking this because
there's lots of it around, e.g. all the world administrative regions
available as .RData files from http://gadm.org/
It's just a question of readability: Better to have a clear statement of
inheritance rather than plowing through the representation list for
empty name fields. And easier to discuss (e.g., section 9.3 of SoDA).
You're hardly the only sinner in the flock. I imagine many packages on
CRAN would have failed by now if there was a problem. I only complain
about it when feeling fussy.
John
.
On 09/18/2011 11:04 PM, John Chambers wrote:
The distinction here is "simple inheritance" ("Software for Data
Analysis", p. 346). Your first example is simple inheritance (would be
clearer if you used the contains= argument). In the second version you
supply an explicit coerce method, so method dispatch can no longer just
pass in the object from the subclass, but has to call the coerce method
explicitly. Details in the reference.
If you need to have an explicit coerce method, it's possible to emulate
simple inheritance, but the programming may be more subtle than you want
to take on. When your method is called, it actually gets also an
argument strict= which will be FALSE for method dispatch. You need to
take account of the strict= argument in writing your method. See ?setAs
for a few more details. Someone on the list may have an example.
John
On 9/18/11 3:33 AM, Edzer Pebesma wrote:
As a follow-up, I managed to isolate the problem I sent earlier this
week, and reduced it to a small case (I'm using R 2.13.1,
i486-pc-linux-gnu (32-bit)).
The following script does what I expect:
setClass("A", representation(x = "numeric"))
setClass("AB", representation("A"))
setGeneric("doNothing<-", function(obj, value)
standardGeneric("doNothing<-"))
setReplaceMethod("doNothing", c("A", "character"),
function(obj, value) obj)
x = new("AB", x = 10)
doNothing(x) = "irrelevant"
class(x)
setAs("AB", "A", function(from) new("A", x = from@x))
x = new("AB", x = 10)
doNothing(x) = "irrelevant"
class(x)
and results in class(x) being "AB".
However, the following, very similar script:
setClass("A", representation(x = "numeric"))
setClass("AB", representation("A"))
setGeneric("doNothing<-", function(obj, value)
standardGeneric("doNothing<-"))
setReplaceMethod("doNothing", c("A", "character"),
function(obj, value) obj)
setAs("AB", "A", function(from) new("A", x = from@x))
x = new("AB", x = 10)
doNothing(x) = "irrelevant"
class(x)
returns "A" as the class of x. Why is this the case? Is this behaviour
intentional?
Best regards,
On 09/14/2011 11:00 PM, Edzer Pebesma wrote:
List,
In order to get rid of some old, unreadable S3 code in package sp, I'm
trying to rewrite things using S4 methods. Somewhere I fail, and I
cannot sort out why. In order to isolate the problem, I created two
functions, doNothing<- and dosth, and both should do nothing. The issue
is that in most cases they do nothing, but in some cases dosth(obj)
changes the class of obj and breaks with the error. I couldn't find a
pattern when this happens, but have a few cases where it consistently
breaks. Here's the code snippet:
setGeneric("doNothing<-", function(object, value)
standardGeneric("doNothing<-"))
setReplaceMethod("doNothing",
signature(object = "Spatial", value = "ANY"),
function(object, value) object)
dosth = function(obj) {
cl1 = class(obj)
doNothing(obj) = TRUE
cl2 = class(obj)
if (!identical(cl1, cl2)) {
print(paste(cl1, cl2))
stopifnot(identical(cl1, cl2))
}
obj
}
When things go wrong, dosth and doNothing are called with a subclass of
Spatial, e.g. an object of class SpatialGrid, but when this gets in
doNothing, the object is suddenly of class Spatial, and is then
returned
as an object of class Spatial, which should never happen.
For instance, I have a case where consistently
setMethod("fullgrid", c("Spatial"),
function(obj) { is(obj, "SpatialGrid") })
class(g)
[1] "SpatialGrid"
attr(,"package")
[1] "sp"
fullgrid(g)
[1] FALSE
is obviously false, but in other cases it works fine.
When I change the signature of doNothing to signature(object = "ANY",
value = "ANY"), the problem disappears.
I tried to make a self-contained example that reproduced the issue, but
could only get something that worked as expected.
I would appreciate any help or suggestions.
__
R-deve
[Rd] Language definition question - order of argument side effects
I'm interested in the difference between these two intuitively
equivalent sequences that produce different results (in R version
2.13.1 (2011-07-08) 32-bit). I think R's reference counting
optimization is causing this difference in behavior.
> a <- 1
> a+{a[1] <- 20}
[1] 21
> a <- 1
> a[1] <- 1
> a+{a[1] <- 20}
[1] 40
Is one of these the "correct" answer, or is the order of side effects
undefined in these statements? Section 4.3.3 of the R Language
Definition just says that doing assignment in an argument to a
function is "bad style", but doesn't say anything about evaluation
order.
In general, for primitive and internal functions, is a particular
evaluation order for the arguments guaranteed?
Thanks,
Justin Talbot
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Language definition question - order of argument side effects
On 30/09/2011 12:26 PM, Justin Talbot wrote:
I'm interested in the difference between these two intuitively
equivalent sequences that produce different results (in R version
2.13.1 (2011-07-08) 32-bit). I think R's reference counting
optimization is causing this difference in behavior.
> a<- 1
> a+{a[1]<- 20}
[1] 21
> a<- 1
> a[1]<- 1
> a+{a[1]<- 20}
[1] 40
Is one of these the "correct" answer, or is the order of side effects
undefined in these statements? Section 4.3.3 of the R Language
Definition just says that doing assignment in an argument to a
function is "bad style", but doesn't say anything about evaluation
order.
In general, for primitive and internal functions, is a particular
evaluation order for the arguments guaranteed?
In general, evaluation order is undefined. I was surprised by the
result, but I think you're right about the explanation. In particular:
a<- 1
.Internal(inspect(a))
@4a06440 14 REALSXP g0c1 [NAM(2)] (len=1, tl=0) 1
a[1]<- 1
.Internal(inspect(a))
@4a06300 14 REALSXP g0c1 [NAM(1)] (len=1, tl=0) 1
The only difference is in the "named" value.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
