Re: [Rd] Large discrepancies in the same object being saved to .RData
On 10/07/2010 10:10 PM, bill.venab...@csiro.au wrote:
Well, I have answered one of my questions below. The hidden
environment is attached to the 'terms' component of v1.
To see this
lapply(v1, environment)
$coefficients
NULL
$residuals
NULL
$effects
NULL
$rank
NULL
$fitted.values
NULL
$assign
NULL
$qr
NULL
$df.residual
NULL
$xlevels
NULL
$call
NULL
$terms
$model
NULL
rm(junk, envir = with(v1, environment(terms)))
usedVcells()
[1] 96532
This is still a bit of a trap for young (and old!) players...
I think the main point in my mind is why is it that object.size()
excludes enclosing environments in its reckonings?
I think the idea is that the environment is not part of the object, it
is just referenced by the object. In fact, there are at least two
references to the environment in your second example:
environment(v1$terms)
and
attr(v1$terms, ".Environment")
both refer to it. So you can't just add the size of an environment every
time you come across it, you would need to keep track of whether it had
already been counted or not. So as ?object.size says,
"Associated space (e.g. the environment of a function and what the
pointer in a ‘EXTPTRSXP’ points to) is not included in the
calculation."
If you really want to know how much space an object will take when saved,
probably the only reliable way is to save the object and look at how much space
the file takes.
Duncan Murdoch
Bill Venables.
-Original Message-
From: Venables, Bill (CMIS, Cleveland)
Sent: Sunday, 11 July 2010 11:40 AM
To: 'Duncan Murdoch'; 'Paul Johnson'
Cc: 'r-devel@r-project.org'; Taylor, Julian (CMIS, Waite Campus)
Subject: RE: [Rd] Large discrepancies in the same object being saved to .RData
I'm still a bit puzzled by the original question. I don't think it
has much to do with .RData files and their sizes. For me the puzzle
comes much earlier. Here is an example of what I mean using a little
session
usedVcells <- function() gc()["Vcells", "used"]
usedVcells()### the base load
[1] 96345
### Now look at what happens when a function returns a formula as the
### value, with a big item floating around in the function closure:
f0 <- function() {
+ junk <- rnorm(1000)
+ y ~ x
+ }
v0 <- f0()
usedVcells() ### much bigger than base, why?
[1] 10096355
v0 ### no obvious envirnoment
y ~ x
object.size(v0) ### so far, no clue given where
### the extra Vcells are located.
372 bytes
### Does v0 have an enclosing environment?
environment(v0) ### yep.
ls(envir = environment(v0)) ### as expected, there's the junk
[1] "junk"
rm(junk, envir = environment(v0)) ### this does the trick.
usedVcells()
[1] 96355
### Now consider a second example where the object
### is not a formula, but contains one.
f1 <- function() {
+ junk <- rnorm(1000)
+ x <- 1:3
+ y <- rnorm(3)
+ lm(y ~ x)
+ }
v1 <- f1()
usedVcells() ### as might have been expected.
[1] 10096455
### in this case, though, there is no
### (obvious) enclosing environment
environment(v1)
NULL
object.size(v1) ### so where are the junk Vcells located?
7744 bytes
ls(envir = environment(v1)) ### clearly wil not work
Error in ls(envir = environment(v1)) : invalid 'envir' argument
rm(v1) ### removing the object does clear out the junk.
usedVcells()
[1] 96366
And in this second case, as noted by Julian Taylor, if you save() the
object the .RData file is also huge. There is an environment attached
to the object somewhere, but it appears to be occluded and entirely
inaccessible. (I have poked around the object components trying to
find the thing but without success.)
Have I missed something?
Bill Venables.
-Original Message-
From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org] On
Behalf Of Duncan Murdoch
Sent: Sunday, 11 July 2010 10:36 AM
To: Paul Johnson
Cc: r-devel@r-project.org
Subject: Re: [Rd] Large discrepancies in the same object being saved to .RData
On 10/07/2010 2:33 PM, Paul Johnson wrote:
On Wed, Jul 7, 2010 at 7:12 AM, Duncan Murdoch wrote:
On 06/07/2010 9:04 PM, julian.tay...@csiro.au wrote:
Hi developers,
After some investigation I have found there can be large discrepancies in
the same object being saved as an external "xx.RData" file. The immediate
repercussion of this is the possible increased size of your .RData workspace
for no apparent reason.
I haven't worked through your example, but in general the way that local
objects get captured is when part of the return value includes an
environment.
Hi, can I ask a follow up question?
Is there a tool to browse *.Rdata files without loading them into R?
I don't know of one. You can load the whole file into an empty
environment, but then
Re: [Rd] Large discrepancies in the same object being saved to .RData
Well, I have answered one of my questions below. The hidden
environment is attached to the 'terms' component of v1.
To see this
> lapply(v1, environment)
$coefficients
NULL
$residuals
NULL
$effects
NULL
$rank
NULL
$fitted.values
NULL
$assign
NULL
$qr
NULL
$df.residual
NULL
$xlevels
NULL
$call
NULL
$terms
$model
NULL
> rm(junk, envir = with(v1, environment(terms)))
> usedVcells()
[1] 96532
>
This is still a bit of a trap for young (and old!) players...
I think the main point in my mind is why is it that object.size()
excludes enclosing environments in its reckonings?
Bill Venables.
-Original Message-
From: Venables, Bill (CMIS, Cleveland)
Sent: Sunday, 11 July 2010 11:40 AM
To: 'Duncan Murdoch'; 'Paul Johnson'
Cc: 'r-devel@r-project.org'; Taylor, Julian (CMIS, Waite Campus)
Subject: RE: [Rd] Large discrepancies in the same object being saved to .RData
I'm still a bit puzzled by the original question. I don't think it
has much to do with .RData files and their sizes. For me the puzzle
comes much earlier. Here is an example of what I mean using a little
session
> usedVcells <- function() gc()["Vcells", "used"]
> usedVcells()### the base load
[1] 96345
### Now look at what happens when a function returns a formula as the
### value, with a big item floating around in the function closure:
> f0 <- function() {
+ junk <- rnorm(1000)
+ y ~ x
+ }
> v0 <- f0()
> usedVcells() ### much bigger than base, why?
[1] 10096355
> v0 ### no obvious envirnoment
y ~ x
> object.size(v0) ### so far, no clue given where
### the extra Vcells are located.
372 bytes
### Does v0 have an enclosing environment?
> environment(v0) ### yep.
> ls(envir = environment(v0)) ### as expected, there's the junk
[1] "junk"
> rm(junk, envir = environment(v0)) ### this does the trick.
> usedVcells()
[1] 96355
### Now consider a second example where the object
### is not a formula, but contains one.
> f1 <- function() {
+ junk <- rnorm(1000)
+ x <- 1:3
+ y <- rnorm(3)
+ lm(y ~ x)
+ }
> v1 <- f1()
> usedVcells() ### as might have been expected.
[1] 10096455
### in this case, though, there is no
### (obvious) enclosing environment
> environment(v1)
NULL
> object.size(v1) ### so where are the junk Vcells located?
7744 bytes
> ls(envir = environment(v1)) ### clearly wil not work
Error in ls(envir = environment(v1)) : invalid 'envir' argument
> rm(v1) ### removing the object does clear out the junk.
> usedVcells()
[1] 96366
>
And in this second case, as noted by Julian Taylor, if you save() the
object the .RData file is also huge. There is an environment attached
to the object somewhere, but it appears to be occluded and entirely
inaccessible. (I have poked around the object components trying to
find the thing but without success.)
Have I missed something?
Bill Venables.
-Original Message-
From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org] On
Behalf Of Duncan Murdoch
Sent: Sunday, 11 July 2010 10:36 AM
To: Paul Johnson
Cc: r-devel@r-project.org
Subject: Re: [Rd] Large discrepancies in the same object being saved to .RData
On 10/07/2010 2:33 PM, Paul Johnson wrote:
> On Wed, Jul 7, 2010 at 7:12 AM, Duncan Murdoch
> wrote:
>
>> On 06/07/2010 9:04 PM, julian.tay...@csiro.au wrote:
>>
>>> Hi developers,
>>>
>>>
>>>
>>> After some investigation I have found there can be large discrepancies in
>>> the same object being saved as an external "xx.RData" file. The immediate
>>> repercussion of this is the possible increased size of your .RData workspace
>>> for no apparent reason.
>>>
>>>
>>>
>>>
>> I haven't worked through your example, but in general the way that local
>> objects get captured is when part of the return value includes an
>> environment.
>>
>
> Hi, can I ask a follow up question?
>
> Is there a tool to browse *.Rdata files without loading them into R?
>
I don't know of one. You can load the whole file into an empty
environment, but then you lose information about "where did it come from"?
Duncan Murdoch
> In HDF5 (a data storage format we use sometimes), there is a CLI
> program "h5dump" that will spit out line-by-line all the contents of a
> storage entity. It will literally track through all the metadata, all
> the vectors of scores, etc. I've found that handy to "see what's
> really in there" in cases like the one that OP asked about.
> Sometimes, we find that there are things that are "in there" by
> mistake, as Duncan describes, and then we can try to figure why they
> are in there.
>
> pj
>
>
>
__
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] Large discrepancies in the same object being saved to .RData
I'm still a bit puzzled by the original question. I don't think it
has much to do with .RData files and their sizes. For me the puzzle
comes much earlier. Here is an example of what I mean using a little
session
> usedVcells <- function() gc()["Vcells", "used"]
> usedVcells()### the base load
[1] 96345
### Now look at what happens when a function returns a formula as the
### value, with a big item floating around in the function closure:
> f0 <- function() {
+ junk <- rnorm(1000)
+ y ~ x
+ }
> v0 <- f0()
> usedVcells() ### much bigger than base, why?
[1] 10096355
> v0 ### no obvious envirnoment
y ~ x
> object.size(v0) ### so far, no clue given where
### the extra Vcells are located.
372 bytes
### Does v0 have an enclosing environment?
> environment(v0) ### yep.
> ls(envir = environment(v0)) ### as expected, there's the junk
[1] "junk"
> rm(junk, envir = environment(v0)) ### this does the trick.
> usedVcells()
[1] 96355
### Now consider a second example where the object
### is not a formula, but contains one.
> f1 <- function() {
+ junk <- rnorm(1000)
+ x <- 1:3
+ y <- rnorm(3)
+ lm(y ~ x)
+ }
> v1 <- f1()
> usedVcells() ### as might have been expected.
[1] 10096455
### in this case, though, there is no
### (obvious) enclosing environment
> environment(v1)
NULL
> object.size(v1) ### so where are the junk Vcells located?
7744 bytes
> ls(envir = environment(v1)) ### clearly wil not work
Error in ls(envir = environment(v1)) : invalid 'envir' argument
> rm(v1) ### removing the object does clear out the junk.
> usedVcells()
[1] 96366
>
And in this second case, as noted by Julian Taylor, if you save() the
object the .RData file is also huge. There is an environment attached
to the object somewhere, but it appears to be occluded and entirely
inaccessible. (I have poked around the object components trying to
find the thing but without success.)
Have I missed something?
Bill Venables.
-Original Message-
From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org] On
Behalf Of Duncan Murdoch
Sent: Sunday, 11 July 2010 10:36 AM
To: Paul Johnson
Cc: r-devel@r-project.org
Subject: Re: [Rd] Large discrepancies in the same object being saved to .RData
On 10/07/2010 2:33 PM, Paul Johnson wrote:
> On Wed, Jul 7, 2010 at 7:12 AM, Duncan Murdoch
> wrote:
>
>> On 06/07/2010 9:04 PM, julian.tay...@csiro.au wrote:
>>
>>> Hi developers,
>>>
>>>
>>>
>>> After some investigation I have found there can be large discrepancies in
>>> the same object being saved as an external "xx.RData" file. The immediate
>>> repercussion of this is the possible increased size of your .RData workspace
>>> for no apparent reason.
>>>
>>>
>>>
>>>
>> I haven't worked through your example, but in general the way that local
>> objects get captured is when part of the return value includes an
>> environment.
>>
>
> Hi, can I ask a follow up question?
>
> Is there a tool to browse *.Rdata files without loading them into R?
>
I don't know of one. You can load the whole file into an empty
environment, but then you lose information about "where did it come from"?
Duncan Murdoch
> In HDF5 (a data storage format we use sometimes), there is a CLI
> program "h5dump" that will spit out line-by-line all the contents of a
> storage entity. It will literally track through all the metadata, all
> the vectors of scores, etc. I've found that handy to "see what's
> really in there" in cases like the one that OP asked about.
> Sometimes, we find that there are things that are "in there" by
> mistake, as Duncan describes, and then we can try to figure why they
> are in there.
>
> pj
>
>
>
__
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] Large discrepancies in the same object being saved to .RData
On 10/07/2010 2:33 PM, Paul Johnson wrote: On Wed, Jul 7, 2010 at 7:12 AM, Duncan Murdoch wrote: On 06/07/2010 9:04 PM, julian.tay...@csiro.au wrote: Hi developers, After some investigation I have found there can be large discrepancies in the same object being saved as an external "xx.RData" file. The immediate repercussion of this is the possible increased size of your .RData workspace for no apparent reason. I haven't worked through your example, but in general the way that local objects get captured is when part of the return value includes an environment. Hi, can I ask a follow up question? Is there a tool to browse *.Rdata files without loading them into R? I don't know of one. You can load the whole file into an empty environment, but then you lose information about "where did it come from"? Duncan Murdoch In HDF5 (a data storage format we use sometimes), there is a CLI program "h5dump" that will spit out line-by-line all the contents of a storage entity. It will literally track through all the metadata, all the vectors of scores, etc. I've found that handy to "see what's really in there" in cases like the one that OP asked about. Sometimes, we find that there are things that are "in there" by mistake, as Duncan describes, and then we can try to figure why they are in there. pj __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Large discrepancies in the same object being saved to .RData
On Wed, Jul 7, 2010 at 7:12 AM, Duncan Murdoch wrote: > On 06/07/2010 9:04 PM, julian.tay...@csiro.au wrote: >> >> Hi developers, >> >> >> >> After some investigation I have found there can be large discrepancies in >> the same object being saved as an external "xx.RData" file. The immediate >> repercussion of this is the possible increased size of your .RData workspace >> for no apparent reason. >> >> >> > I haven't worked through your example, but in general the way that local > objects get captured is when part of the return value includes an > environment. Hi, can I ask a follow up question? Is there a tool to browse *.Rdata files without loading them into R? In HDF5 (a data storage format we use sometimes), there is a CLI program "h5dump" that will spit out line-by-line all the contents of a storage entity. It will literally track through all the metadata, all the vectors of scores, etc. I've found that handy to "see what's really in there" in cases like the one that OP asked about. Sometimes, we find that there are things that are "in there" by mistake, as Duncan describes, and then we can try to figure why they are in there. pj -- Paul E. Johnson Professor, Political Science 1541 Lilac Lane, Room 504 University of Kansas __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Set the number of threads using openmp with .C
On 10 July 2010 at 13:01, Dirk Eddelbuettel wrote:
|
| Eduardo,
|
| On 10 July 2010 at 19:31, Eduardo García wrote:
| | Hi everybody! Could somebody help me with the following?
| |
| | I'm trying to run a simple Hello World code in openmp using .C function. The
| | C code i have is:
| |
| | #include
| | #include
| | #include
| |
| | void hello_omp(int *n) {
| |int th_id, nthreads;
| |omp_set_num_threads(*n);
| |#pragma omp parallel private(th_id)
| |{
| | th_id = omp_get_thread_num();
| | Rprintf("Hello World from thread %d\n", th_id);
| | #pragma omp barrier
| | if ( th_id == 0 ) {
| |nthreads = omp_get_num_threads();
| |Rprintf("There are %d threads\n",nthreads);
| | }
| |}
| | }
| |
| | Where n is the number of threads that i want.
| |
| | I compite it with "R CMD SHLIB hello_openmp_R.c -fopenmp" and when I try to
| | run it in R using:
| |
| | dyn.load("hello_openmp_R.so")
| | hello_omp=function(n){.C("hello_omp",as.integer(n))}
| | hello_omp(3)
| | hello_omp(2)
| |
| | Only 1 thread is been used, instead of 3 and 2:
| |
| | > hello_omp(3)
| | Hello World from thread 0
| | There are 1 threads
| | [[1]]
| | [1] 3
| |
| |
| | > hello_omp(2)
| | Hello World from thread 0
| | There are 1 threads
| | [[1]]
| | [1] 2
| |
| | I also tried to set OMP_NUM_THREADS=3 in the Konsole with "export
| | OMP_NUM_THREADS=3", in the .c file directory, but it seems that R don't
| | recognize it when calls .C
| |
| | I am using R version 2.10.1 in Ubuntu 9.10 - Karmic Koala, but i'm newbie in
| | Linux.
| |
| | Thanks a lot in advance for your help !*
|
| You were almost there, but your compile instructions were wrong. You must
| pass -fopenmp to gcc. Which you tried, alas wrongly, and then overlooked the
| warnings (and I called your file eduardo.c here) :
|
|gcc -std=gnu99 -I/usr/share/R/include -fpic -O3 -Wall -pipe -c
eduardo.c -o eduardo.o
|eduardo.c: In function ‘hello_omp’:
|eduardo.c:7: warning: ignoring #pragma omp parallel
|eduardo.c:11: warning: ignoring #pragma omp barrier
|
| One way of passing argument to gcc via 'R CMF foo' is to to use the
| PKG_CPPFLAGS and PKG_LIBS arguments. The following shell script builds and
| runs the code:
|
|#!/bin/sh
|
|PKG_CPPFLAGS="-fopenmp" \
|PKG_LIBS="-lgomp" \
|R CMD SHLIB eduardo.c
|
|cat < dyn.load("eduardo.so")
|> hello_omp=function(n){.C("hello_omp",as.integer(n))}
|> hello_omp(3)
|Hello World from thread 0
|Hello World from thread 2
|Hello World from thread 1
|There are 3 threads
|[[1]]
|[1] 3
|
|> hello_omp(2)
|Hello World from thread 0
|Hello World from thread 1
|There are 2 threads
|[[1]]
|[1] 2
|
|>
|e...@max:/tmp$
|
| Have a look at the CRAN package 'inline' which allows you to compile, load,
| link such short code snippets much more easily.
|
| Lastly, one word of caution. R is famously single-threaded. You may get
| yourself into trouble with OpenMP unless you set locks rather carefully.
| There is of course the famous example of Luke Tierney's pnmath (at
| http://www.stat.uiowa.edu/~luke/R/experimental/) so there is also some scope
| for using this.
PS: Using PKG_CFLAGS is slightly better style; the outcome is the same. See
e.g. src/Makevars and src/Makevars.win in the pnmath package referenced
above.
D.
|
| Hope this helps.
|
| --
| Regards, Dirk
|
| __
| R-devel@r-project.org mailing list
| https://stat.ethz.ch/mailman/listinfo/r-devel
--
Regards, Dirk
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Set the number of threads using openmp with .C
Eduardo,
On 10 July 2010 at 19:31, Eduardo García wrote:
| Hi everybody! Could somebody help me with the following?
|
| I'm trying to run a simple Hello World code in openmp using .C function. The
| C code i have is:
|
| #include
| #include
| #include
|
| void hello_omp(int *n) {
|int th_id, nthreads;
|omp_set_num_threads(*n);
|#pragma omp parallel private(th_id)
|{
| th_id = omp_get_thread_num();
| Rprintf("Hello World from thread %d\n", th_id);
| #pragma omp barrier
| if ( th_id == 0 ) {
|nthreads = omp_get_num_threads();
|Rprintf("There are %d threads\n",nthreads);
| }
|}
| }
|
| Where n is the number of threads that i want.
|
| I compite it with "R CMD SHLIB hello_openmp_R.c -fopenmp" and when I try to
| run it in R using:
|
| dyn.load("hello_openmp_R.so")
| hello_omp=function(n){.C("hello_omp",as.integer(n))}
| hello_omp(3)
| hello_omp(2)
|
| Only 1 thread is been used, instead of 3 and 2:
|
| > hello_omp(3)
| Hello World from thread 0
| There are 1 threads
| [[1]]
| [1] 3
|
|
| > hello_omp(2)
| Hello World from thread 0
| There are 1 threads
| [[1]]
| [1] 2
|
| I also tried to set OMP_NUM_THREADS=3 in the Konsole with "export
| OMP_NUM_THREADS=3", in the .c file directory, but it seems that R don't
| recognize it when calls .C
|
| I am using R version 2.10.1 in Ubuntu 9.10 - Karmic Koala, but i'm newbie in
| Linux.
|
| Thanks a lot in advance for your help !*
You were almost there, but your compile instructions were wrong. You must
pass -fopenmp to gcc. Which you tried, alas wrongly, and then overlooked the
warnings (and I called your file eduardo.c here) :
gcc -std=gnu99 -I/usr/share/R/include -fpic -O3 -Wall -pipe -c
eduardo.c -o eduardo.o
eduardo.c: In function ‘hello_omp’:
eduardo.c:7: warning: ignoring #pragma omp parallel
eduardo.c:11: warning: ignoring #pragma omp barrier
One way of passing argument to gcc via 'R CMF foo' is to to use the
PKG_CPPFLAGS and PKG_LIBS arguments. The following shell script builds and
runs the code:
#!/bin/sh
PKG_CPPFLAGS="-fopenmp" \
PKG_LIBS="-lgomp" \
R CMD SHLIB eduardo.c
cat < dyn.load("eduardo.so")
> hello_omp=function(n){.C("hello_omp",as.integer(n))}
> hello_omp(3)
Hello World from thread 0
Hello World from thread 2
Hello World from thread 1
There are 3 threads
[[1]]
[1] 3
> hello_omp(2)
Hello World from thread 0
Hello World from thread 1
There are 2 threads
[[1]]
[1] 2
>
e...@max:/tmp$
Have a look at the CRAN package 'inline' which allows you to compile, load,
link such short code snippets much more easily.
Lastly, one word of caution. R is famously single-threaded. You may get
yourself into trouble with OpenMP unless you set locks rather carefully.
There is of course the famous example of Luke Tierney's pnmath (at
http://www.stat.uiowa.edu/~luke/R/experimental/) so there is also some scope
for using this.
Hope this helps.
--
Regards, Dirk
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Set the number of threads using openmp with .C
Hi everybody! Could somebody help me with the following?
I'm trying to run a simple Hello World code in openmp using .C function. The
C code i have is:
#include
#include
#include
void hello_omp(int *n) {
int th_id, nthreads;
omp_set_num_threads(*n);
#pragma omp parallel private(th_id)
{
th_id = omp_get_thread_num();
Rprintf("Hello World from thread %d\n", th_id);
#pragma omp barrier
if ( th_id == 0 ) {
nthreads = omp_get_num_threads();
Rprintf("There are %d threads\n",nthreads);
}
}
}
Where n is the number of threads that i want.
I compite it with "R CMD SHLIB hello_openmp_R.c -fopenmp" and when I try to
run it in R using:
dyn.load("hello_openmp_R.so")
hello_omp=function(n){.C("hello_omp",as.integer(n))}
hello_omp(3)
hello_omp(2)
Only 1 thread is been used, instead of 3 and 2:
> hello_omp(3)
Hello World from thread 0
There are 1 threads
[[1]]
[1] 3
> hello_omp(2)
Hello World from thread 0
There are 1 threads
[[1]]
[1] 2
I also tried to set OMP_NUM_THREADS=3 in the Konsole with "export
OMP_NUM_THREADS=3", in the .c file directory, but it seems that R don't
recognize it when calls .C
I am using R version 2.10.1 in Ubuntu 9.10 - Karmic Koala, but i'm newbie in
Linux.
Thanks a lot in advance for your help !*
*
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Defining a method that behaves like '$'?
On Jul 10, 2010, at 7:24 AM, Barry Rowlingson wrote: > On Fri, Jul 9, 2010 at 2:10 PM, Renaud Gaujoux > wrote: >> I do not want to access the slot itself but its content: a:toto would be >> a...@slot1[['toto']]. >> The thing is that I would like to have two different methods: '$' (that I >> already have) and another one to define, ideally that behaves like '$'. >> So in brief: >> - a:toto would be for a...@slot1[['toto']] >> - a$tata would be for a...@slot2[['tata']] >> >> But apparently it might not be possible. >> > > Even if possible, definitely not desirable. As already mentioned, a:b > is the sequence a to b (as in 0:10), so it's going to look weird to > anyone who hasn't noticed your definition. Also, it looks fairly > meaningless. By which I mean there's no obvious reason why a colon > should do what you want it to do. There's also no obvious reason why a > dollar sign does what it does (whats it got to do with dollars?) but > we've had it for 20 years so we're stuck with it. > > Write a method for your objects and force your users to do a bit more > typing as a trade-off for legibility: > > slot1(a,"toto") > > is a lot more readable than a:toto (assuming you replace 'slot1' with > something meaningful). > > Remember, code is most likely to be written once, and read many times > - so make it easy for readers! Just to throw in another $0.02, in hindsight, not fully understanding the context of Renaud's original query, this may be a situation where implementing relevant extractor functions would make sense. Consider functions such as coef(), effects(), fitted() etc. for regression models. These allow you and your users to have functions that return components of your object class without being concerned about the internal structure of your object. Importantly, you and your users will not be affected by future changes to your object structure that you may find you have to implement over time. You simply modify the extractor functions as required when the internal structure of your class changes, so that they can be used post-change, without breaking existing code. So for example: toto(a) would return a...@slot1[['toto']] and tata(a) would return a...@slot2[['tata']]. Food for thought. Marc __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Defining a method that behaves like '$'?
On Fri, Jul 9, 2010 at 2:10 PM, Renaud Gaujoux wrote: > I do not want to access the slot itself but its content: a:toto would be > a...@slot1[['toto']]. > The thing is that I would like to have two different methods: '$' (that I > already have) and another one to define, ideally that behaves like '$'. > So in brief: > - a:toto would be for a...@slot1[['toto']] > - a$tata would be for a...@slot2[['tata']] > > But apparently it might not be possible. > Even if possible, definitely not desirable. As already mentioned, a:b is the sequence a to b (as in 0:10), so it's going to look weird to anyone who hasn't noticed your definition. Also, it looks fairly meaningless. By which I mean there's no obvious reason why a colon should do what you want it to do. There's also no obvious reason why a dollar sign does what it does (whats it got to do with dollars?) but we've had it for 20 years so we're stuck with it. Write a method for your objects and force your users to do a bit more typing as a trade-off for legibility: slot1(a,"toto") is a lot more readable than a:toto (assuming you replace 'slot1' with something meaningful). Remember, code is most likely to be written once, and read many times - so make it easy for readers! Barry __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
