[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