[Rd] Suggestion for serialization performance improvement on Windows
Dear R developers, The slow performance of serializing to a raw vector on Windows is an issue that has appeared in this list before. It appears to be due to the frequent use of realloc from the resize_buffer method in serialize.c. I suggest a more granular, but still incremental, re-allocation of memory. For example change near the top of resize_buffer to: R_size_t newsize = needed + 65536 - (needed % 65536); or some other similar small multiple of a typical system page size. I have found this to dramatically improve performance of serialization to raw vectors on Windows. Best, Bryan __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Strange R object
Gabor Grothendieck wrote:
> I have *** attached *** an RData file containing an R object that
> is acting strangely.
>
> Try this in a fresh workspace. Do not load zoo or any other package.
> We load the object, zz2, from the attached RData file. It is just
> the number 1 with the class c("zooreg", "zoo").
>
> Now create an S3 print routine that simply prints an X when given
> an object of class "zoo".
>
> If we use print on the object it produces an X but not if we just
> enter it at the console. Also the object is not identical to its
> dput output.
>
> How can such an object exist? What is it about the object that is
> different from structure(1, class = c("zoo", "zooreg")) ?
>
There's a bit in the SEXP structure that is supposed to be turned on
when an object has an S3 class. This is where implicit print looks,
whereas explicit print looks, er, elsewhere. Notice that
> is.object(zz2)
[1] FALSE
> class(zz2) <- class(zz2)
> zz2
X
> is.object(zz2)
[1] TRUE
Whenever the same information is stored in two ways, there is a risk of
inconsistency, so it is not too strange that you can have an ill-formed
.Rdata file (if you save zz2 back out, after the above fixup, line 11
changes from 526 to 782, corresponding to the bit being turned on).
I don't think it is the job of load() to verify object structures, since
there is no end to that task. Rather, we shouldn't create them in the
first place, but you give us no clues as to how that object got made.
--
Peter Dalgaard
Center for Statistics, Copenhagen Business School
Phone: (+45)38153501
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Strange R object
On Fri, Jul 9, 2010 at 5:09 AM, Peter Dalgaard wrote:
> Gabor Grothendieck wrote:
>> I have *** attached *** an RData file containing an R object that
>> is acting strangely.
>>
>> Try this in a fresh workspace. Do not load zoo or any other package.
>> We load the object, zz2, from the attached RData file. It is just
>> the number 1 with the class c("zooreg", "zoo").
>>
>> Now create an S3 print routine that simply prints an X when given
>> an object of class "zoo".
>>
>> If we use print on the object it produces an X but not if we just
>> enter it at the console. Also the object is not identical to its
>> dput output.
>>
>> How can such an object exist? What is it about the object that is
>> different from structure(1, class = c("zoo", "zooreg")) ?
>>
>
> There's a bit in the SEXP structure that is supposed to be turned on
> when an object has an S3 class. This is where implicit print looks,
> whereas explicit print looks, er, elsewhere. Notice that
>
>> is.object(zz2)
> [1] FALSE
>> class(zz2) <- class(zz2)
>> zz2
> X
>> is.object(zz2)
> [1] TRUE
>
> Whenever the same information is stored in two ways, there is a risk of
> inconsistency, so it is not too strange that you can have an ill-formed
> .Rdata file (if you save zz2 back out, after the above fixup, line 11
> changes from 526 to 782, corresponding to the bit being turned on).
>
> I don't think it is the job of load() to verify object structures, since
> there is no end to that task. Rather, we shouldn't create them in the
> first place, but you give us no clues as to how that object got made.
>
This was originally a large object in a program that uses a variety of
packages and it took quite a long time just to narrow it down to the
point where I had an object sufficiently small to post. Its not even
clear at what point the object goes bad but your class(x) <- class(x)
trick helped a lot and I have now been able to recreate it in a simple
manner.
Below we create a new S3 class "X" with an Ops.X and print.X method.
We then create an object x of that class which is just 1 with a class
of "X". When we multiply 1*x we get the bad object. 1*x and x have
the same dput output but compare as FALSE. 1*x is not printed by
print.X even though it is of class "X" while x is printed by print.X .
If we assign 1*x to xx and use your class assignment trick (class(xx)
<- class(xx)) then xx prints as expected even though it did not prior
to the class assignment.
> Ops.X <- function(e1, e2) { print("Ops.X"); NextMethod(.Generic) }
> print.X <- function(x, ...) print("print.X")
> x <- structure(1, class = "X")
> dput(x)
structure(1, class = "X")
> dput(1*x)
[1] "Ops.X"
structure(1, class = "X")
> identical(x, 1*x)
[1] "Ops.X"
[1] FALSE
> 1*x
[1] "Ops.X"
[1] 1
attr(,"class")
[1] "X"
> x
[1] "print.X"
> xx <- 1*x
[1] "Ops.X"
> class(xx) <- class(xx)
> xx
[1] "print.X"
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Defining a method that behaves like '$'?
Hi, is there a way to define a method say '$$' that would behave like '$' and allow calls like 'a$$name'? Thanks. Renaud -- Renaud Gaujoux Computational Biology - University of Cape Town South Africa ### UNIVERSITY OF CAPE TOWN This e-mail is subject to the UCT ICT policies and e-mail disclaimer published on our website at http://www.uct.ac.za/about/policies/emaildisclaimer/ or obtainable from +27 21 650 4500. This e-mail is intended only for the person(s) to whom it is addressed. If the e-mail has reached you in error, please notify the author. If you are not the intended recipient of the e-mail you may not use, disclose, copy, redirect or print the content. If this e-mail is not related to the business of UCT it is sent by the sender in the sender's individual capacity. ### __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Strange R object
Gabor Grothendieck wrote:
> On Fri, Jul 9, 2010 at 5:09 AM, Peter Dalgaard wrote:
>> Gabor Grothendieck wrote:
>>> I have *** attached *** an RData file containing an R object that
>>> is acting strangely.
>>>
>>> Try this in a fresh workspace. Do not load zoo or any other package.
>>> We load the object, zz2, from the attached RData file. It is just
>>> the number 1 with the class c("zooreg", "zoo").
>>>
>>> Now create an S3 print routine that simply prints an X when given
>>> an object of class "zoo".
>>>
>>> If we use print on the object it produces an X but not if we just
>>> enter it at the console. Also the object is not identical to its
>>> dput output.
>>>
>>> How can such an object exist? What is it about the object that is
>>> different from structure(1, class = c("zoo", "zooreg")) ?
>>>
>> There's a bit in the SEXP structure that is supposed to be turned on
>> when an object has an S3 class. This is where implicit print looks,
>> whereas explicit print looks, er, elsewhere. Notice that
>>
>>> is.object(zz2)
>> [1] FALSE
>>> class(zz2) <- class(zz2)
>>> zz2
>> X
>>> is.object(zz2)
>> [1] TRUE
>>
>> Whenever the same information is stored in two ways, there is a risk of
>> inconsistency, so it is not too strange that you can have an ill-formed
>> .Rdata file (if you save zz2 back out, after the above fixup, line 11
>> changes from 526 to 782, corresponding to the bit being turned on).
>>
>> I don't think it is the job of load() to verify object structures, since
>> there is no end to that task. Rather, we shouldn't create them in the
>> first place, but you give us no clues as to how that object got made.
>>
>
> This was originally a large object in a program that uses a variety of
> packages and it took quite a long time just to narrow it down to the
> point where I had an object sufficiently small to post. Its not even
> clear at what point the object goes bad but your class(x) <- class(x)
> trick helped a lot and I have now been able to recreate it in a simple
> manner.
>
> Below we create a new S3 class "X" with an Ops.X and print.X method.
> We then create an object x of that class which is just 1 with a class
> of "X". When we multiply 1*x we get the bad object. 1*x and x have
> the same dput output but compare as FALSE. 1*x is not printed by
> print.X even though it is of class "X" while x is printed by print.X .
> If we assign 1*x to xx and use your class assignment trick (class(xx)
> <- class(xx)) then xx prints as expected even though it did not prior
> to the class assignment.
>
>> Ops.X <- function(e1, e2) { print("Ops.X"); NextMethod(.Generic) }
>> print.X <- function(x, ...) print("print.X")
>> x <- structure(1, class = "X")
>> dput(x)
> structure(1, class = "X")
>> dput(1*x)
> [1] "Ops.X"
> structure(1, class = "X")
>> identical(x, 1*x)
> [1] "Ops.X"
> [1] FALSE
>> 1*x
> [1] "Ops.X"
> [1] 1
> attr(,"class")
> [1] "X"
>> x
> [1] "print.X"
>> xx <- 1*x
> [1] "Ops.X"
>> class(xx) <- class(xx)
>> xx
> [1] "print.X"
Or, to minimize it further:
> x <- structure(1, class="y")
> is.object(x)
[1] TRUE
> is.object(x*1)
[1] TRUE
> is.object(1*x)
[1] FALSE
> class(x*1)
[1] "y"
> class(1*x)
[1] "y"
Yup, that looks like a bug.
--
Peter Dalgaard
Center for Statistics, Copenhagen Business School
Phone: (+45)38153501
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Defining a method that behaves like '$'?
Le 09/07/10 14:18, Renaud Gaujoux a écrit :
Hi,
is there a way to define a method say '$$' that would behave like '$'
and allow calls like 'a$$name'?
Thanks.
Renaud
No. This is not grammatically valid syntax:
> parse( text = 'a$$name' )
Erreur dans parse(text = "a$$name") : '$' inattendu(e) dans "a$$"
But you can define custom methods for $.
setClass( "Foo", representation( n = "integer" ) )
setMethod( "$", "Foo", function(x, name ){
function( ) rnorm( x...@n )
} )
foo <- new( "Foo", n = 10L )
foo$bla( )
Romain
--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/aJHNLV : Rmetrics slides
|- http://bit.ly/98Uf7u : Rcpp 0.8.1
`- http://bit.ly/c6YnCi : graph gallery collage
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Defining a method that behaves like '$'?
On 09/07/2010 8:18 AM, Renaud Gaujoux wrote: Hi, is there a way to define a method say '$$' that would behave like '$' and allow calls like 'a$$name'? No, the parser handles a fixed syntax, and that expression is not legal. You could do it with a %$$% name using the infix operator syntax. (I think the description in the R Language Definition suggests this is not legal, since $$ is not a valid name, but it does currently work and that's unlikely to change.) Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Defining a method that behaves like '$'?
Alright. Maybe the symbol I chose was not appropriate. I tried ':' to be able to do 'a:name' with 'a' a S4 object. I get the following error: Error in genericForPrimitive(f) : methods may not be defined for primitive function ":" in this version of R Does there exist any symbol that would be suitable for the job? Thanks -- Renaud Gaujoux Computational Biology - University of Cape Town South Africa On 09/07/2010 14:29, Duncan Murdoch wrote: On 09/07/2010 8:18 AM, Renaud Gaujoux wrote: Hi, is there a way to define a method say '$$' that would behave like '$' and allow calls like 'a$$name'? No, the parser handles a fixed syntax, and that expression is not legal. You could do it with a %$$% name using the infix operator syntax. (I think the description in the R Language Definition suggests this is not legal, since $$ is not a valid name, but it does currently work and that's unlikely to change.) Duncan Murdoch ### UNIVERSITY OF CAPE TOWN This e-mail is subject to the UCT ICT policies and e-mail disclaimer published on our website at http://www.uct.ac.za/about/policies/emaildisclaimer/ or obtainable from +27 21 650 4500. This e-mail is intended only for the person(s) to whom it is addressed. If the e-mail has reached you in error, please notify the author. If you are not the intended recipient of the e-mail you may not use, disclose, copy, redirect or print the content. If this e-mail is not related to the business of UCT it is sent by the sender in the sender's individual capacity. ### __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Defining a method that behaves like '$'?
You were, in effect, trying to overload the ":" operator, which is of course for defining sequences. If you are using S4 methods, what is wrong with using the default "@" as the extraction syntax (eg. a...@name) to get at slots? See ?"@" and ?slot HTH, Marc Schwartz On Jul 9, 2010, at 7:49 AM, Renaud Gaujoux wrote: > Alright. > Maybe the symbol I chose was not appropriate. I tried ':' to be able to do > 'a:name' with 'a' a S4 object. > I get the following error: > Error in genericForPrimitive(f) : > methods may not be defined for primitive function ":" in this version of R > > Does there exist any symbol that would be suitable for the job? > Thanks > > -- > Renaud Gaujoux > Computational Biology - University of Cape Town > South Africa > > > On 09/07/2010 14:29, Duncan Murdoch wrote: >> On 09/07/2010 8:18 AM, Renaud Gaujoux wrote: >>> Hi, >>> >>> is there a way to define a method say '$$' that would behave like '$' and >>> allow calls like 'a$$name'? >> No, the parser handles a fixed syntax, and that expression is not legal. >> You could do it with >> >> a %$$% name >> >> using the infix operator syntax. (I think the description in the R Language >> Definition suggests this is not legal, since $$ is not a valid name, but it >> does currently work and that's unlikely to change.) >> >> Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Defining a method that behaves like '$'?
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. -- Renaud Gaujoux Computational Biology - University of Cape Town South Africa On 09/07/2010 14:58, Marc Schwartz wrote: You were, in effect, trying to overload the ":" operator, which is of course for defining sequences. If you are using S4 methods, what is wrong with using the default "@" as the extraction syntax (eg. a...@name) to get at slots? See ?"@" and ?slot HTH, Marc Schwartz On Jul 9, 2010, at 7:49 AM, Renaud Gaujoux wrote: Alright. Maybe the symbol I chose was not appropriate. I tried ':' to be able to do 'a:name' with 'a' a S4 object. I get the following error: Error in genericForPrimitive(f) : methods may not be defined for primitive function ":" in this version of R Does there exist any symbol that would be suitable for the job? Thanks -- Renaud Gaujoux Computational Biology - University of Cape Town South Africa On 09/07/2010 14:29, Duncan Murdoch wrote: On 09/07/2010 8:18 AM, Renaud Gaujoux wrote: Hi, is there a way to define a method say '$$' that would behave like '$' and allow calls like 'a$$name'? No, the parser handles a fixed syntax, and that expression is not legal. You could do it with a %$$% name using the infix operator syntax. (I think the description in the R Language Definition suggests this is not legal, since $$ is not a valid name, but it does currently work and that's unlikely to change.) Duncan Murdoch ### UNIVERSITY OF CAPE TOWN This e-mail is subject to the UCT ICT policies and e-mail disclaimer published on our website at http://www.uct.ac.za/about/policies/emaildisclaimer/ or obtainable from +27 21 650 4500. This e-mail is intended only for the person(s) to whom it is addressed. If the e-mail has reached you in error, please notify the author. If you are not the intended recipient of the e-mail you may not use, disclose, copy, redirect or print the content. If this e-mail is not related to the business of UCT it is sent by the sender in the sender's individual capacity. ### __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Defining a method that behaves like '$'?
I am certainly not an expert in S4 and know enough to be dangerous.
That being said, I used setMethod() as Romain had done. I would defer to others
with greater experience as to the pros and cons, including the risk of
confusion, but here is one approach, extending the example in ?slot:
setClass("track", representation(x = "numeric", y = "numeric", z = "list"))
myTrack <- new("track", x = -4:4, y = exp(-4:4), z = list(A = 1:5, B = 7:12))
setMethod( "$", "track", function(x, name){
slot(x, "z")[[name]]
})
> myTrack
An object of class "track"
Slot "x":
[1] -4 -3 -2 -1 0 1 2 3 4
Slot "y":
[1] 0.01831564 0.04978707 0.13533528 0.36787944 1.
[6] 2.71828183 7.38905610 20.08553692 54.59815003
Slot "z":
$A
[1] 1 2 3 4 5
$B
[1] 7 8 9 10 11 12
> mytr...@z
$A
[1] 1 2 3 4 5
$B
[1] 7 8 9 10 11 12
# Default
> mytr...@z$a
[1] 1 2 3 4 5
> mytr...@z$b
[1] 7 8 9 10 11 12
# Use the new '$' method
> myTrack$A
[1] 1 2 3 4 5
> myTrack$B
[1] 7 8 9 10 11 12
Not sure if that gets you something along the lines of what you wanted, but
perhaps it is helpful.
Marc
On Jul 9, 2010, at 8:10 AM, 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.
>
> --
> Renaud Gaujoux
> Computational Biology - University of Cape Town
> South Africa
>
>
> On 09/07/2010 14:58, Marc Schwartz wrote:
>> You were, in effect, trying to overload the ":" operator, which is of course
>> for defining sequences.
>>
>> If you are using S4 methods, what is wrong with using the default "@" as the
>> extraction syntax (eg. a...@name) to get at slots?
>>
>> See ?"@" and ?slot
>>
>> HTH,
>>
>> Marc Schwartz
>>
>> On Jul 9, 2010, at 7:49 AM, Renaud Gaujoux wrote:
>>
>>
>>> Alright.
>>> Maybe the symbol I chose was not appropriate. I tried ':' to be able to do
>>> 'a:name' with 'a' a S4 object.
>>> I get the following error:
>>> Error in genericForPrimitive(f) :
>>> methods may not be defined for primitive function ":" in this version of R
>>>
>>> Does there exist any symbol that would be suitable for the job?
>>> Thanks
>>>
>>> --
>>> Renaud Gaujoux
>>> Computational Biology - University of Cape Town
>>> South Africa
>>>
>>>
>>> On 09/07/2010 14:29, Duncan Murdoch wrote:
>>>
On 09/07/2010 8:18 AM, Renaud Gaujoux wrote:
> Hi,
>
> is there a way to define a method say '$$' that would behave like '$' and
> allow calls like 'a$$name'?
>
No, the parser handles a fixed syntax, and that expression is not legal.
You could do it with
a %$$% name
using the infix operator syntax. (I think the description in the R
Language Definition suggests this is not legal, since $$ is not a valid
name, but it does currently work and that's unlikely to change.)
Duncan Murdoch
>>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Mysterious behavior
I had trouble with some tests for the survival suite last night that I cannot explain. Framework: Ubuntu Linux, R2.11. For testing survival I have a separate directory and Makefile. I pull everything into the local .RData, no packages, library, or namespace. (It's easier to add test modifications to a routine in a chain of calls). A test of survreg + psline would fail because splines is not automatically loaded in this scenario. In my console window type > library(splines) > fit <- survreg(Surv(time, status) ~ ph.ecog + spline(age), data=lung) as the first 2 lines a a new session (the lung data is also saved) and up would pop an error message about having <2.10 version of survival. And it is true that I had such a thing in my ~/RLib. But there is no mention of either the local or the system survival library when I type search(), and .Autoloaded is NULL. I'm mystified as to how R decided to use that library, and what it was trying to pull from it. I removed it from ~/Rlib and the message went away, but now I'm not so sure that this was a good idea. Is something now being automatically snatched out of the standard survival library? If so that compromises the integrity of my testbed. How do I find out? Terry Therneau __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Mysterious behavior
On 09/07/2010 10:55 AM, Therneau, Terry M., Ph.D. wrote: I had trouble with some tests for the survival suite last night that I cannot explain. Framework: Ubuntu Linux, R2.11. For testing survival I have a separate directory and Makefile. I pull everything into the local .RData, no packages, library, or namespace. (It's easier to add test modifications to a routine in a chain of calls). A test of survreg + psline would fail because splines is not automatically loaded in this scenario. In my console window type > library(splines) > fit <- survreg(Surv(time, status) ~ ph.ecog + spline(age), data=lung) as the first 2 lines a a new session (the lung data is also saved) and up would pop an error message about having <2.10 version of survival. And it is true that I had such a thing in my ~/RLib. But there is no mention of either the local or the system survival library when I type search(), and .Autoloaded is NULL. Could you show us the result of .libPaths(), search(), searchpaths() and sessionInfo()? Duncan Murdoch I'm mystified as to how R decided to use that library, and what it was trying to pull from it. I removed it from ~/Rlib and the message went away, but now I'm not so sure that this was a good idea. Is something now being automatically snatched out of the standard survival library? If so that compromises the integrity of my testbed. How do I find out? Terry Therneau __ 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] Strange R object
On Fri, Jul 9, 2010 at 5:25 AM, Peter Dalgaard wrote:
> Gabor Grothendieck wrote:
>> On Fri, Jul 9, 2010 at 5:09 AM, Peter Dalgaard wrote:
>>> Gabor Grothendieck wrote:
I have *** attached *** an RData file containing an R object that
is acting strangely.
Try this in a fresh workspace. Do not load zoo or any other package.
We load the object, zz2, from the attached RData file. It is just
the number 1 with the class c("zooreg", "zoo").
Now create an S3 print routine that simply prints an X when given
an object of class "zoo".
If we use print on the object it produces an X but not if we just
enter it at the console. Also the object is not identical to its
dput output.
How can such an object exist? What is it about the object that is
different from structure(1, class = c("zoo", "zooreg")) ?
>>> There's a bit in the SEXP structure that is supposed to be turned on
>>> when an object has an S3 class. This is where implicit print looks,
>>> whereas explicit print looks, er, elsewhere. Notice that
>>>
is.object(zz2)
>>> [1] FALSE
class(zz2) <- class(zz2)
zz2
>>> X
is.object(zz2)
>>> [1] TRUE
>>>
>>> Whenever the same information is stored in two ways, there is a risk of
>>> inconsistency, so it is not too strange that you can have an ill-formed
>>> .Rdata file (if you save zz2 back out, after the above fixup, line 11
>>> changes from 526 to 782, corresponding to the bit being turned on).
>>>
>>> I don't think it is the job of load() to verify object structures, since
>>> there is no end to that task. Rather, we shouldn't create them in the
>>> first place, but you give us no clues as to how that object got made.
>>>
>>
>> This was originally a large object in a program that uses a variety of
>> packages and it took quite a long time just to narrow it down to the
>> point where I had an object sufficiently small to post. Its not even
>> clear at what point the object goes bad but your class(x) <- class(x)
>> trick helped a lot and I have now been able to recreate it in a simple
>> manner.
>>
>> Below we create a new S3 class "X" with an Ops.X and print.X method.
>> We then create an object x of that class which is just 1 with a class
>> of "X". When we multiply 1*x we get the bad object. 1*x and x have
>> the same dput output but compare as FALSE. 1*x is not printed by
>> print.X even though it is of class "X" while x is printed by print.X .
>> If we assign 1*x to xx and use your class assignment trick (class(xx)
>> <- class(xx)) then xx prints as expected even though it did not prior
>> to the class assignment.
>>
>>> Ops.X <- function(e1, e2) { print("Ops.X"); NextMethod(.Generic) }
>>> print.X <- function(x, ...) print("print.X")
>>> x <- structure(1, class = "X")
>>> dput(x)
>> structure(1, class = "X")
>>> dput(1*x)
>> [1] "Ops.X"
>> structure(1, class = "X")
>>> identical(x, 1*x)
>> [1] "Ops.X"
>> [1] FALSE
>>> 1*x
>> [1] "Ops.X"
>> [1] 1
>> attr(,"class")
>> [1] "X"
>>> x
>> [1] "print.X"
>>> xx <- 1*x
>> [1] "Ops.X"
>>> class(xx) <- class(xx)
>>> xx
>> [1] "print.X"
>
> Or, to minimize it further:
>
>> x <- structure(1, class="y")
>> is.object(x)
> [1] TRUE
>> is.object(x*1)
> [1] TRUE
>> is.object(1*x)
> [1] FALSE
>> class(x*1)
> [1] "y"
>> class(1*x)
> [1] "y"
>
> Yup, that looks like a bug.
I recently came across the following surprising behaviour which turns
out to be the same issue. I had been meaning to ask for an
explanation.
> x <- 1:20
> class(x)
[1] "integer"
> is.object(x)
[1] FALSE
> print.integer <- function(x) print(x %% 5)
> print(x)
[1] 1 2 3 4 0 1 2 3 4 0 1 2 3 4 0 1 2 3 4 0
> x
[1] 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
-Deepayan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Strange R object
On Jul 9, 2010, at 12:41 PM, Deepayan Sarkar wrote:
> On Fri, Jul 9, 2010 at 5:25 AM, Peter Dalgaard wrote:
>> Gabor Grothendieck wrote:
>>> On Fri, Jul 9, 2010 at 5:09 AM, Peter Dalgaard wrote:
Gabor Grothendieck wrote:
> I have *** attached *** an RData file containing an R object that
> is acting strangely.
>
> Try this in a fresh workspace. Do not load zoo or any other package.
> We load the object, zz2, from the attached RData file. It is just
> the number 1 with the class c("zooreg", "zoo").
>
> Now create an S3 print routine that simply prints an X when given
> an object of class "zoo".
>
> If we use print on the object it produces an X but not if we just
> enter it at the console. Also the object is not identical to its
> dput output.
>
> How can such an object exist? What is it about the object that is
> different from structure(1, class = c("zoo", "zooreg")) ?
>
There's a bit in the SEXP structure that is supposed to be turned on
when an object has an S3 class. This is where implicit print looks,
whereas explicit print looks, er, elsewhere. Notice that
> is.object(zz2)
[1] FALSE
> class(zz2) <- class(zz2)
> zz2
X
> is.object(zz2)
[1] TRUE
Whenever the same information is stored in two ways, there is a risk of
inconsistency, so it is not too strange that you can have an ill-formed
.Rdata file (if you save zz2 back out, after the above fixup, line 11
changes from 526 to 782, corresponding to the bit being turned on).
I don't think it is the job of load() to verify object structures, since
there is no end to that task. Rather, we shouldn't create them in the
first place, but you give us no clues as to how that object got made.
>>>
>>> This was originally a large object in a program that uses a variety of
>>> packages and it took quite a long time just to narrow it down to the
>>> point where I had an object sufficiently small to post. Its not even
>>> clear at what point the object goes bad but your class(x) <- class(x)
>>> trick helped a lot and I have now been able to recreate it in a simple
>>> manner.
>>>
>>> Below we create a new S3 class "X" with an Ops.X and print.X method.
>>> We then create an object x of that class which is just 1 with a class
>>> of "X". When we multiply 1*x we get the bad object. 1*x and x have
>>> the same dput output but compare as FALSE. 1*x is not printed by
>>> print.X even though it is of class "X" while x is printed by print.X .
>>> If we assign 1*x to xx and use your class assignment trick (class(xx)
>>> <- class(xx)) then xx prints as expected even though it did not prior
>>> to the class assignment.
>>>
Ops.X <- function(e1, e2) { print("Ops.X"); NextMethod(.Generic) }
print.X <- function(x, ...) print("print.X")
x <- structure(1, class = "X")
dput(x)
>>> structure(1, class = "X")
dput(1*x)
>>> [1] "Ops.X"
>>> structure(1, class = "X")
identical(x, 1*x)
>>> [1] "Ops.X"
>>> [1] FALSE
1*x
>>> [1] "Ops.X"
>>> [1] 1
>>> attr(,"class")
>>> [1] "X"
x
>>> [1] "print.X"
xx <- 1*x
>>> [1] "Ops.X"
class(xx) <- class(xx)
xx
>>> [1] "print.X"
>>
>> Or, to minimize it further:
>>
>>> x <- structure(1, class="y")
>>> is.object(x)
>> [1] TRUE
>>> is.object(x*1)
>> [1] TRUE
>>> is.object(1*x)
>> [1] FALSE
>>> class(x*1)
>> [1] "y"
>>> class(1*x)
>> [1] "y"
>>
>> Yup, that looks like a bug.
>
> I recently came across the following surprising behaviour which turns
> out to be the same issue. I had been meaning to ask for an
> explanation.
>
>> x <- 1:20
>> class(x)
> [1] "integer"
>> is.object(x)
> [1] FALSE
>> print.integer <- function(x) print(x %% 5)
>> print(x)
> [1] 1 2 3 4 0 1 2 3 4 0 1 2 3 4 0 1 2 3 4 0
>> x
> [1] 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
>
... that is an entirely different issue. x is still not an object because it
doesn't have any explicit S3 class so it has nothing in common with the case
discussed. This is about P in REPL which uses PrintValueEnv which is turn
dispatches to print() only for objects (see main and print).
Cheers,
Simon
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Telling Windows how to find DLL's from R?
Is it possible to set Windows' search path from within R, or to tell Windows how to find a DLL in some other way from R? Specifically, if a package DLL depends on another DLL the normal requirement is that the second DLL be in the search path so Windows can find it (there are other tricks, but they apply at the Windows level, not at the R level). Thanks, Dominick [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Telling Windows how to find DLL's from R?
On 09/07/2010 2:38 PM, Dominick Samperi wrote: Is it possible to set Windows' search path from within R, or to tell Windows how to find a DLL in some other way from R? Specifically, if a package DLL depends on another DLL the normal requirement is that the second DLL be in the search path so Windows can find it (there are other tricks, but they apply at the Windows level, not at the R level). I haven't tried this, but can't you use Sys.setenv() to change the PATH to what you want? Presumably you'll want to change it back afterwards. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Telling Windows how to find DLL's from R?
On 07/09/2010 11:38 AM, Dominick Samperi wrote: > Is it possible to set Windows' search path from within R, or > to tell Windows how to find a DLL in some other way from > R? Specifically, if a package DLL depends on another DLL > the normal requirement is that the second DLL be in the > search path so Windows can find it (there are other tricks, > but they apply at the Windows level, not at the R level). This thread https://stat.ethz.ch/pipermail/r-devel/2008-January/047961.html might be relevant, especially the DLLpath argument to dyn.load. Martin > > Thanks, > Dominick > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Martin Morgan Computational Biology / Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N. PO Box 19024 Seattle, WA 98109 Location: Arnold Building M1 B861 Phone: (206) 667-2793 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Telling Windows how to find DLL's from R?
On Fri, Jul 9, 2010 at 3:48 PM, Duncan Murdoch wrote:
> On 09/07/2010 2:38 PM, Dominick Samperi wrote:
>
>> Is it possible to set Windows' search path from within R, or
>> to tell Windows how to find a DLL in some other way from
>> R? Specifically, if a package DLL depends on another DLL
>> the normal requirement is that the second DLL be in the
>> search path so Windows can find it (there are other tricks,
>> but they apply at the Windows level, not at the R level).
>>
>>
>
>
> I haven't tried this, but can't you use Sys.setenv() to change the PATH to
> what you want? Presumably you'll want to change it back afterwards.
>
Thanks, good suggestion, but it does not seem to work. If PATH is updated in
this way the
change is local to the current process, not to the top-level Windows
process, so a subsequent
dyn.load('foo.dll') will fail if foo.dll depends on bar.dll, unless bar.dll
is placed in the search
path for the top-level shell. Seems like this needs to be done as part of
system
startup outside of R.
On the other hand, if foo.dll is the package library for package foo, and if
foo
depends on package bar, then there is no need to place bar.dll in the
top-level
search path. R takes care of this (more typical) situation.
Dominick
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Telling Windows how to find DLL's from R?
Thanks Duncan, Martin: Please ignore my remarks about "top-level Windows context". I made a mistake. After correcting my mistake Duncan's suggestion worked, and the solution is very similar to what the DLLpath argument of dyn.load() does: Sys.setenv() can be used to edit PATH so that Windows finds DLL's where you want them to be found. (Well almost, because the windows search algorithm does not just use PATH.) Dominick [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
