[Rd] S4 class help pages [Sec=Unclassified]
Hi,
I am working on producing an R package containing mostly S4 classes and methods.
I have generated and filled out all the necessary .Rd files but find that once
installed I am unable to access help pages for the classes using the
?package::classname-class syntax that is suggested when using the ?? apropos
search. This lists my package classes and the class help pages. Instead, the
"Arithmetic Operators" help page is always loaded. I can load the pages I want
via links like \linkS4class{classname} in my package help page.
I have played with a couple of other packages and see the same problem. Is
there a different syntax to access these S4 class help pages rather than
?package::classname-class?
Thanks
Troy
___
Australian Antarctic Division - Commonwealth of Australia
IMPORTANT: This transmission is intended for the addressee only. If you are not
the
intended recipient, you are notified that use or dissemination of this
communication is
strictly prohibited by Commonwealth law. If you have received this transmission
in error,
please notify the sender immediately by e-mail or by telephoning +61 3 6232
3209 and
DELETE the message.
Visit our web site at http://www.antarctica.gov.au/
___
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Recursion error after upgrade to R_2.11.1 [Sec=Unclassified]
Hi all, After an upgrade from R_2.10.1 to R_2.11.1 I am now getting the following error: Error: evaluation nested too deeply: infinite recursion / options(expressions=)? This occurs in the initialize method of S4 classes where I was initialising attributes eg: .Object[['realtimeState']] <- list() I can avoid this new error by altering the code to do: .Object$realtimeState <- list() OR .obj...@.xdata$realtimestate <- list() My classes all extend .environment and store all changeable data as per above (in environment .xData slot) rather than in normal class slots because I am able to achieve much quicker execution times without all the copy-on-change cost that results from passing these objects containing large amounts of slot-based data. Can anyone provide a reason for the changes that have brought about the recursion issue? Is there a better way to achieve the pass-by-reference style objects I am after? Thanks Troy ___ Australian Antarctic Division - Commonwealth of Australia IMPORTANT: This transmission is intended for the addressee only. If you are not the intended recipient, you are notified that use or dissemination of this communication is strictly prohibited by Commonwealth law. If you have received this transmission in error, please notify the sender immediately by e-mail or by telephoning +61 3 6232 3209 and DELETE the message. Visit our web site at http://www.antarctica.gov.au/ ___ [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] S4 class help pages [Sec=Unclassified]
> -Original Message-
> From: Duncan Murdoch [mailto:murdoch.dun...@gmail.com]
> Sent: Monday, 4 October 2010 11:09 PM
> To: Troy Robertson
> Cc: 'r-devel@R-project.org'
> Subject: Re: [Rd] S4 class help pages [Sec=Unclassified]
>
>
> On 04/10/2010 12:14 AM, Troy Robertson wrote:
> > Hi,
> >
> > I am working on producing an R package containing mostly S4 classes
> > and methods. I have generated and filled out all the necessary .Rd
> > files but find that once installed I am unable to access help pages
> > for the classes using the ?package::classname-class syntax that is
> > suggested when using the ?? apropos search. This lists my package
> > classes and the class help pages. Instead, the "Arithmetic
> Operators"
> > help page is always loaded. I can load the pages I want via links
> > like \linkS4class{classname} in my package help page.
> >
> > I have played with a couple of other packages and see the same
> > problem. Is there a different syntax to access these S4 class help
> > pages rather than ?package::classname-class?
>
> The problem is the parsing: that is parsed as
> `?`(stats4::mle - class), i.e. there's a subtraction there,
> not a name with a hyphen in it. So you're seeing help on subtraction.
>
> You can get what you want with class?stats4::mle.
>
> I'll see if I can fix the advice from ??.
>
> Duncan Murdoch
>
> > Thanks
> >
> > Troy
Cheers Duncan,
Both your suggestions do the trick.
i.e. class?stats4::mle and ?stats4::`mle-class`
Troy
___
Australian Antarctic Division - Commonwealth of Australia
IMPORTANT: This transmission is intended for the addressee only. If you are not
the
intended recipient, you are notified that use or dissemination of this
communication is
strictly prohibited by Commonwealth law. If you have received this transmission
in error,
please notify the sender immediately by e-mail or by telephoning +61 3 6232
3209 and
DELETE the message.
Visit our web site at http://www.antarctica.gov.au/
___
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Recursion error after upgrade to R_2.11.1 [Sec=Unclassified]
Resending this in plain text, after realising the html text hadn't been posted (oops). Hi all, After an upgrade from R_2.10.1 to R_2.11.1 I am now getting the following error: Error: evaluation nested too deeply: infinite recursion / options(expressions=)? This occurs in the initialize method of S4 classes where I was initialising attributes eg: .Object[['realtimeState']] <- list() I can mostly avoid this new error by altering the code to do: .Object$realtimeState <- list() OR .obj...@.xdata$realtimestate <- list() But there are also times when I need to do .Object[realtimeState] <- list(NULL) in order to specifically set it to NULL (rather than have it removed) which I think is also causing me grief. My classes all extend .environment and store all non-static data as per above (in environment .xData slot) rather than in normal class slots because I am able to achieve much quicker execution times without all the copy-on-change cost that results from passing these objects containing large amounts of slot-based data. Can anyone provide a reason for the changes that have brought about the recursion issue? Is there a better way to achieve the pass-by-reference style objects I am after? Thanks Troy ___ Australian Antarctic Division - Commonwealth of Australia IMPORTANT: This transmission is intended for the addressee only. If you are not the intended recipient, you are notified that use or dissemination of this communication is strictly prohibited by Commonwealth law. If you have received this transmission in error, please notify the sender immediately by e-mail or by telephoning +61 3 6232 3209 and DELETE the message. Visit our web site at http://www.antarctica.gov.au/ ___ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Recursion error after upgrade to R_2.11.1 [Sec=Unclassified]
Hi all,
After no replies to my previous message I thought I might show some code to
demonstrate the change and again seek any explanation for the error now thrown
by my code after upgrading from 2.10.1 to 2.11.1.
Thanks
Troy
setClass("PortableObject",
representation(test1= "character"),
prototype( test1 = ""),
contains = ".environment"
)
setMethod("initialize", "PortableObject",
function(.Object, ..., .xData=new.env(parent=emptyenv())) {
.Object <- callNextMethod(.Object, ..., .xData=.xData)
.obj...@test1 <- "Foo"
# Following line works under 2.10.1 but now throws
# Error: evaluation nested too deeply: infinite recursion /
options(expressions=)?
#.Object[["test2"]] <- "Bar"
# The following does what I want though
.Object$test3 <- "Baa"
return(.Object)
}
)
e <- new("PortableObject")
alterEGo <- function(o = "EPOCObject") {
o...@test1 <- "Boo"
# Following line works under 2.10.1 but now throws
# Error: evaluation nested too deeply: infinite recursion /
options(expressions=)?
o[["test2"]] <- "Who"
# The following does what I want though
o$test3 <- "Hoo"
# NOTE: No return
}
alterEGo(e)
e...@test1
e$test2
e[["test3"]]
e...@.xdata[["test3"]]
___
Australian Antarctic Division - Commonwealth of Australia
IMPORTANT: This transmission is intended for the addressee only. If you are not
the
intended recipient, you are notified that use or dissemination of this
communication is
strictly prohibited by Commonwealth law. If you have received this transmission
in error,
please notify the sender immediately by e-mail or by telephoning +61 3 6232
3209 and
DELETE the message.
Visit our web site at http://www.antarctica.gov.au/
___
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Recursion error after upgrade to R_2.11.1 [Sec=Unclassified] [Sec=Unclassified]
>
> On 10/06/2010 06:12 PM, Troy Robertson wrote:
> > Hi all,
> >
> > After no replies to my previous message I thought I might show some
> > code to demonstrate the change and again seek any
> explanation for the
> > error now thrown by my code after upgrading from 2.10.1 to 2.11.1.
> >
> > Thanks
> > Troy
> >
> > setClass("PortableObject",
> > representation(test1= "character"),
> >
> > prototype( test1 = ""),
> > contains = ".environment"
> > )
> >
> > setMethod("initialize", "PortableObject",
> > function(.Object, ..., .xData=new.env(parent=emptyenv())) {
> > .Object <- callNextMethod(.Object, ...,
> .xData=.xData)
> >
> > .obj...@test1 <- "Foo"
> > # Following line works under 2.10.1 but now throws
> > # Error: evaluation nested too deeply:
> infinite recursion / options(expressions=)?
> > #.Object[["test2"]] <- "Bar"
> > # The following does what I want though
> > .Object$test3 <- "Baa"
> >
> > return(.Object)
> > }
> > )
> >
> > e <- new("PortableObject")
>
> The explicit example does help -- it's clear what bug you are
> encountering. Here's the code in R-2.10
>
> > selectMethod("[[<-", ".environment")
> Method Definition:
>
> function (x, i, j, ..., value)
> {
> call <- sys.call()
> call[[2]] <- x...@.data
> eval.parent(call)
> x
> }
>
>
> and 2.11.1
>
> > selectMethod("[[<-", ".environment")
> Method Definition:
>
> function (x, i, j, ..., value)
> {
> .local <- function (x, i, j, ..., exact = TRUE, value)
> {
> call <- sys.call()
> call[[2]] <- x...@.data
> eval.parent(call)
> x
> }
> .local(x, i, j, ..., value = value)
> }
>
> Apparently the 'exact' argument has been added, and because
> the method signature differs from the generic, a .local
> function is created. That 'sys.call()' originally returned
> the environment in which the generic was called, but now it
> returns the environment in which .local is defined. And so
> eval() keeps evaluating .local(). This I think is a bug.
Yes, afer the email from William Dunlop, I found this difference in the methods
between 2.10.1 and 2.11.1
I had a play and by adding my own method to overload "[[<-" for my
PortableObject was able to reinstate the original functionality without the
recursive error.
setMethod("[[<-", "PortableObject",
function (x, i, j, ..., value)
{
call <- sys.call()
call[[2]] <- x...@.data
eval.parent(call)
x
}
)
>
> For what it's worth, if I were interested in minimizing
> copying I would set up initialize so that it ended with
> callNextMethod(<...>), on the hopes that the method
> eventually called would take care not to make too many copies
> on slot assignment.
>
> Martin
>
Hmmm, not sure what you mean here? My code passes objects such as these as
parameters to other S4 classes which alter their data. If the .xData slot is
used then I have no need to return the object. No copy-on-change is performed
but data held by the PortableObject is modified. This speeds up my execution
time by a LARGE amount.
I could very well have things all arse-about, having come from a Java OO
background, but this is the only way I have been able to create a
pass-by-reference paradigm using S4 classes. Any suggestions for alternative
solutions would be greatfully received.
Troy
> >
> > alterEGo <- function(o = "EPOCObject") {
> > o...@test1 <- "Boo"
> >
> > # Following line works under 2.10.1 but now throws
> > # Error: evaluation nested too deeply: infinite
> recursion / options(expressions=)?
> > o[["test2"]] <- "Who"
> > # The following does what I want though
> > o$test3 <- "Hoo"
> >
> > # NOTE: No return
> > }
> >
> > alterEGo(e)
> > e...@test1
> > e$test2
> > e[["test3"]]
> > e...@.xdata[["test3"]]
> >
___
Australian Antarctic Division - Commonwealth of Australia
IMPORTANT: This transmission is intended for the addressee only. If you are not
the
intended recipient, you are notified that use or dissemination of this
communication is
strictly prohibited by Commonwealth law. If you have received this transmission
in error,
please notify the sender immediately by e-mail or by telephoning +61 3 6232
3209 and
DELETE the message.
Visit our web site at http://www.antarctica.gov.au/
___
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Recursion error after upgrade to R_2.11.1 [Sec=Unclassified] [Sec=Unclassified]
> -Original Message-
> From: Martin Maechler [mailto:maech...@stat.math.ethz.ch]
> Sent: Thursday, 7 October 2010 9:50 PM
> To: Troy Robertson
> Cc: 'Martin Morgan'; 'r-devel@R-project.org'; 'John Chambers'
> Subject: Re: [Rd] Recursion error after upgrade to R_2.11.1
> [Sec=Unclassified] [Sec=Unclassified]
>
>
> >>>>> "TR" == Troy Robertson
> >>>>> on Thu, 7 Oct 2010 13:50:49 +1100 writes:
>
> >>
> >> On 10/06/2010 06:12 PM, Troy Robertson wrote:
> >> > Hi all,
> >> >
> >> > After no replies to my previous message I thought I
> might show some
> >> > code to demonstrate the change and again seek any
> >> explanation for the
> >> > error now thrown by my code after upgrading from
> 2.10.1 to 2.11.1.
> >> >
> >> > Thanks
> >> > Troy
> >> >
> >> > setClass("PortableObject",
> >> > representation(test1= "character"),
> >> >
> >> > prototype( test1 = ""),
> >> > contains = ".environment"
> >> > )
> >> >
> >> > setMethod("initialize", "PortableObject",
> >> > function(.Object, ...,
> .xData=new.env(parent=emptyenv())) {
> >> > .Object <- callNextMethod(.Object, ...,
> >> .xData=.xData)
> >> >
> >> > .obj...@test1 <- "Foo"
> >> > # Following line works under 2.10.1
> but now throws
> >> > # Error: evaluation nested too deeply:
> >> infinite recursion / options(expressions=)?
> >> > #.Object[["test2"]] <- "Bar"
> >> > # The following does what I want though
> >> > .Object$test3 <- "Baa"
> >> >
> >> > return(.Object)
> >> > }
> >> > )
> >> >
> >> > e <- new("PortableObject")
> >>
> >> The explicit example does help -- it's clear what bug you are
> >> encountering. Here's the code in R-2.10
> >>
> >> > selectMethod("[[<-", ".environment")
> >> Method Definition:
> >>
> >> function (x, i, j, ..., value)
> >> {
> >> call <- sys.call()
> >> call[[2]] <- x...@.data
> >> eval.parent(call)
> >> x
> >> }
> >>
> >>
> >> and 2.11.1
> >>
> >> > selectMethod("[[<-", ".environment")
> >> Method Definition:
> >>
> >> function (x, i, j, ..., value)
> >> {
> >> .local <- function (x, i, j, ..., exact = TRUE, value)
> >> {
> >> call <- sys.call()
> >> call[[2]] <- x...@.data
> >> eval.parent(call)
> >> x
> >> }
> >> .local(x, i, j, ..., value = value)
> >> }
> >>
> >> Apparently the 'exact' argument has been added, and because
> >> the method signature differs from the generic, a .local
> >> function is created. That 'sys.call()' originally returned
> >> the environment in which the generic was called, but now it
> >> returns the environment in which .local is defined. And so
> >> eval() keeps evaluating .local(). This I think is a bug.
>
> TR> Yes, afer the email from William Dunlop, I found this
> difference in the methods between 2.10.1 and 2.11.1
> TR> I had a play and by adding my own method to overload
> "[[<-" for my PortableObject was able to reinstate the
> original functionality without the recursive error.
>
> TR> setMethod("[[<-", "PortableObject",
> TR> function (x, i, j, ..., value)
> TR> {
> TR> call <- sys.call()
> TR> call[[2]] <- x...@.data
> TR> eval.parent(call)
> TR> x
> TR> }
> TR> )
>
> >>
> >> For what it's worth, if I were interested in minimizing
> >>
Re: [Rd] Recursion error after upgrade to R_2.11.1 [Sec=Unclassified] [Sec=Unclassified]
Thanks Kasper,
I have been meaning to have a good look at some of the Bioconductor source for
a while now. So will check it out.
But I am also quite enthusiastic about what is happening with referenced
classes and will be having a good play around with that in the coming weeks.
Troy
> -Original Message-
> From: Kasper Daniel Hansen [mailto:kasperdanielhan...@gmail.com]
> Sent: Friday, 8 October 2010 3:13 PM
> To: Troy Robertson
> Cc: Martin Maechler; r-devel@R-project.org; John Chambers
> Subject: Re: [Rd] Recursion error after upgrade to R_2.11.1
> [Sec=Unclassified] [Sec=Unclassified]
>
>
> Troy
>
> For what it's worth, the ExpressionSet / eSet class in
> Biobase from Bioconductor has for a long time implemented a
> pass-by-reference system, using amongst other stuff locked
> environments to make sure things are read only. You might
> find this useful to look at.
>
> In general it is hard to complement on your use case without
> knowing the details. I often find that careful programming
> and profiling can make R code much faster than initially
> hypotised. Having said that, sometimes (esp. for very big,
> read-only objects) environments make sense.
>
> Kasper
>
> On Thu, Oct 7, 2010 at 6:52 PM, Troy Robertson
> wrote:
> >> -Original Message-
> >> From: Martin Maechler [mailto:maech...@stat.math.ethz.ch]
> >> Sent: Thursday, 7 October 2010 9:50 PM
> >> To: Troy Robertson
> >> Cc: 'Martin Morgan'; 'r-devel@R-project.org'; 'John Chambers'
> >> Subject: Re: [Rd] Recursion error after upgrade to R_2.11.1
> >> [Sec=Unclassified] [Sec=Unclassified]
> >>
> >>
> >> >>>>> "TR" == Troy Robertson
> >> >>>>> on Thu, 7 Oct 2010 13:50:49 +1100 writes:
> >>
> >> >>
> >> >> On 10/06/2010 06:12 PM, Troy Robertson wrote:
> >> >> > Hi all,
> >> >> >
> >> >> > After no replies to my previous message I thought I might
> >> show some
> >> >> > code to demonstrate the change and again seek any
> >> >> explanation for the
> >> >> > error now thrown by my code after upgrading from
> 2.10.1 to
> >> 2.11.1.
> >> >> >
> >> >> > Thanks
> >> >> > Troy
> >> >> >
> >> >> > setClass("PortableObject",
> >> >> > representation(test1= "character"),
> >> >> >
> >> >> > prototype( test1 = ""),
> >> >> > contains = ".environment"
> >> >> > )
> >> >> >
> >> >> > setMethod("initialize", "PortableObject",
> >> >> > function(.Object, ...,
> >> .xData=new.env(parent=emptyenv())) {
> >> >> > .Object <- callNextMethod(.Object, ...,
> >> >> .xData=.xData)
> >> >> >
> >> >> > .obj...@test1 <- "Foo"
> >> >> > # Following line works under 2.10.1
> >> but now throws
> >> >> > # Error: evaluation nested too deeply:
> >> >> infinite recursion / options(expressions=)?
> >> >> > #.Object[["test2"]] <- "Bar"
> >> >> > # The following does what I want though
> >> >> > .Object$test3 <- "Baa"
> >> >> >
> >> >> > return(.Object)
> >> >> > }
> >> >> > )
> >> >> >
> >> >> > e <- new("PortableObject")
> >> >>
> >> >> The explicit example does help -- it's clear what
> bug you are
> >> >> encountering. Here's the code in R-2.10
> >> >>
> >> >> > selectMethod("[[<-", ".environment")
> >> >> Method Definition:
> >> >>
> >> >> function (x, i, j, ..., value)
> >> >> {
> >> >> call <- sys.call()
> >> >> call[[2]] <- x...@.data
> >> >&
[Rd] Wierd nlm behaviour in 2.10.1 and 2.12.0 [Sec=Unclassified]
Hi all,
When upgrading to 2.11.1 recently I noticed different results being produced by
my code.
After much digging I have finally narrowed it to a call to nlm().
This can be replicated by:
FixedRemovals<-1836180125888
AbStageInitial<-2223033830403
Rates<- 0.3102445
nlm(function(rootM,Abund,Loss,OtherM)
{(Loss-(rootM/(rootM+OtherM)*
(1-exp(-(rootM+OtherM)))*
Abund))^2}
,0.001,print.level=0,fscale=0, gradtol=1E-10, stepmax = 100.0
,Loss=FixedRemovals
,Abund=AbStageInitial
,OtherM=Rates)$estimate
___
Australian Antarctic Division - Commonwealth of Australia
IMPORTANT: This transmission is intended for the addressee only. If you are not
the
intended recipient, you are notified that use or dissemination of this
communication is
strictly prohibited by Commonwealth law. If you have received this transmission
in error,
please notify the sender immediately by e-mail or by telephoning +61 3 6232
3209 and
DELETE the message.
Visit our web site at http://www.antarctica.gov.au/
___
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Wierd nlm behaviour in 2.10.1 and 2.12.0 [Sec=Unclassified]
Hi all,
When upgrading to 2.11.1 recently I noticed different results being produced by
my code.
After MUCH digging into my code I have finally narrowed it to a call to nlm().
The problem actually occurs in 2.10.1 and 2.12.0.
This can be replicated by trying the code below in some different versions of R:
FixedRemovals<-1836180125888
AbStageInitial<-2223033830403
Rates<- 0.3102445
myfunc<-function(rootM,Abund,Loss,OtherM)
{(Loss-(rootM/(rootM+OtherM)*
(1-exp(-(rootM+OtherM)))*
Abund))^2}
nlm(myfunc
,0.001,print.level=0,fscale=0, gradtol=1E-10, stepmax = 100.0
,Loss=FixedRemovals
,Abund=AbStageInitial
,OtherM=Rates)
nlm(myfunc
,0.001,print.level=0,fscale=0, gradtol=1E-10, stepmax = 100.0
,Loss=FixedRemovals
,Abund=AbStageInitial
,OtherM=Rates)$estimate
Why would I be seeing a different value of 'estimate' (or any of the other
returned list items)?
Originally I thought it was 2.11.1 that was giving me the grief with different
output but now I see that in 2.11.1 I get the same value to each returned list
item both ways.
Can anyone explain this?
Thanks
Troy
___
Australian Antarctic Division - Commonwealth of Australia
IMPORTANT: This transmission is intended for the addressee only. If you are not
the
intended recipient, you are notified that use or dissemination of this
communication is
strictly prohibited by Commonwealth law. If you have received this transmission
in error,
please notify the sender immediately by e-mail or by telephoning +61 3 6232
3209 and
DELETE the message.
Visit our web site at http://www.antarctica.gov.au/
___
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wierd nlm behaviour in 2.10.1 and 2.12.0 [Sec=Unclassified]
Thanks heaps Ravi,
I will have to take the modified function to my modeller/statistician and get
him to check it out as I am only a general programmer and do not understand the
significance of your suggested changes. Your changes do look to produce
consistent results though and as John Nash pointed out in an email, the
returned 'code' value was originally 5, indicating a failure. So it looks like
the code I have been using has always been producing erroneous output data :-(
Still not sure why there is a difference between:
nlm(...)$estimate
AND
a<-nlm(...)
a$estimate
in R2.10.1 and R2.12.0beta though but not R2.11.1?
Even if nlm() is failing it should show consistent output I would have thought?
Thanks again for your suggestions Ravi.
Troy
> -Original Message-
> From: Ravi Varadhan [mailto:rvarad...@jhmi.edu]
> Sent: Thursday, 14 October 2010 2:29 AM
> To: 'Ravi Varadhan'; Troy Robertson; 'r-devel@R-project.org'
> Subject: RE: [Rd] Wierd nlm behaviour in 2.10.1 and 2.12.0
> [Sec=Unclassified]
>
>
> Try this:
>
> Myfunc2 <- function(rootM,Abund,Loss,OtherM) {
> # I have scaled the function
> (Loss/Abund - (rootM/(rootM+OtherM)*
> (1-exp(-(rootM+OtherM)^2
> }
>
>
> nlm(myfunc2
>,0.001,print.level=0,fscale=0, gradtol=1E-10, stepmax = 100.0
>,Loss=FixedRemovals
>,Abund=AbStageInitial
>,OtherM=Rates)$estimate
>
> This should work quite robustly under various R versions on
> different platforms.
>
> Ravi.
>
> -Original Message-
> From: r-devel-boun...@r-project.org
> [mailto:r-devel-boun...@r-project.org]
> On Behalf Of Ravi Varadhan
> Sent: Wednesday, October 13, 2010 9:27 AM
> To: 'Troy Robertson'; 'r-devel@R-project.org'
> Subject: Re: [Rd] Wierd nlm behaviour in 2.10.1 and 2.12.0
> [Sec=Unclassified]
>
> Hi Troy,
>
> I think that your problem is poorly scaled. You have
> variables that vary over several orders of magnitude. This
> means that any small changes (due to subtle differences
> between R versions) could cause a big difference in the
> convergence behavior of the algorithms. So, you are asking
> for trouble and you got it. I would scale the problem such
> that the parameters, function and its gradient are
> essentially of the same magnitude.
>
> To paraphrase John Nash, who paraphrased Richard Varga, "It
> is all about scaling".
>
> Furthermore, I would specify the analytic gradient, which
> should be very easy to derive.
>
> Ravi.
>
>
> -Original Message-
> From: r-devel-boun...@r-project.org
> [mailto:r-devel-boun...@r-project.org]
> On Behalf Of Troy Robertson
> Sent: Wednesday, October 13, 2010 1:51 AM
> To: 'r-devel@R-project.org'
> Subject: [Rd] Wierd nlm behaviour in 2.10.1 and 2.12.0
> [Sec=Unclassified]
>
> Hi all,
>
> When upgrading to 2.11.1 recently I noticed different results
> being produced by my code. After MUCH digging into my code I
> have finally narrowed it to a call to nlm(). The problem
> actually occurs in 2.10.1 and 2.12.0.
>
> This can be replicated by trying the code below in some
> different versions of R:
>
> FixedRemovals<-1836180125888
> AbStageInitial<-2223033830403
> Rates<- 0.3102445
> myfunc<-function(rootM,Abund,Loss,OtherM)
> {(Loss-(rootM/(rootM+OtherM)*
> (1-exp(-(rootM+OtherM)))*
> Abund))^2}
>
> nlm(myfunc
>,0.001,print.level=0,fscale=0, gradtol=1E-10, stepmax = 100.0
>,Loss=FixedRemovals
>,Abund=AbStageInitial
>,OtherM=Rates)
>
> nlm(myfunc
>,0.001,print.level=0,fscale=0, gradtol=1E-10, stepmax = 100.0
>,Loss=FixedRemovals
>,Abund=AbStageInitial
>,OtherM=Rates)$estimate
>
> Why would I be seeing a different value of 'estimate' (or any
> of the other returned list items)? Originally I thought it
> was 2.11.1 that was giving me the grief with different output
> but now I see that in 2.11.1 I get the same value to each
> returned list item both ways. Can anyone explain this?
>
> Thanks
>
> Troy
> __
> _
>
> Australian Antarctic Division - Commonwealth of Australia
> IMPORTANT: This transmission is intended for the addressee
> only. If you are not the intended recipient, you are notified
> that use or dissemination of this communication is strictly
> prohibited by Commonwealth law. If you have received this
> transmission in error, please notify the sender immediately
> by e-mail or by telephoning +61 3 6232 3209 and DELETE the message.
> Visit our web site at http://www.antarctica.gov.au/
> __
[Rd] R inline package
Hi all,
I am having some problems with the inline package and maybe someone can
point out what is going wrong?
I have developed a C++ library to assist with an S4 R project I have
been working on for some time. I need to be able to include my package
using the setCMethod() function but it fails to find library header
files and/or the Rcpp.h header if I include that. Yet if I use the
cfunction call first, the exact same setCMethod() call will then work.
I am assuming the Rcpp plugin is being called because of the Rcpp=TRUE
argument to cfunction(), which is setting up the paths to cause the
success of the later setCMethod? I know the setCMethod() call will work
without the includes argument, but I need to be able to add the include
to my library, which also fails unless the cfunction() call has been
made first.
I am using R-2.14.1, Windows 7, inline (0.3.8), Rcpp (0.9.10).
I had to downgrade rTools to 2.14 because of the following problem I
encountered building my dll originally:
http://www.mail-archive.com/rcpp-devel@lists.r-forge.r-project.org/msg03133.html
example:
library(inline)
inc<-c("#include");
sig<-signature(item="character")
code<-"return item;"
setCMethod("getSigItem", sig, body=code, includes=inc, Rcpp=TRUE,
verbose=TRUE)
The above call fails with:
fatal error: Rcpp.h: No such file or directory
The following call works fine:
f<-cfunction(sig, body=code, includes=inc, cppargs=cppa, libargs=liba,
Rcpp=TRUE, verbose=TRUE)
And now the same setCMethod call from above will work:
setCMethod("getSigItem", sig, body=code, includes=inc, Rcpp=TRUE,
verbose=TRUE)
Thanks for any help you can provide
Troy
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] S4 Objects [Sec=Unclassified]
I am new to R programming but have dived into a medium sized modelling software development project. Having come from a Java OO background I have a couple of questions about S4 objects. Is there a way to make S4 slots (and methods) private and hence force the use of accessor methods? Is there a straight-forward way to implement pass-by-reference for method parameters? I am currently returning and overwritting updated objects which is clunky and costly and would like a more efficient way of doing this. Can anyone point me to some useful texts on S4 programming apart from the following: Chambers - Software for Data Analysis: Programming with R Venables - S Programming Thanks heaps Troy ___ Australian Antarctic Division - Commonwealth of Australia IMPORTANT: This transmission is intended for the addressee only. If you are not the intended recipient, you are notified that use or dissemination of this communication is strictly prohibited by Commonwealth law. If you have received this transmission in error, please notify the sender immediately by e-mail or by telephoning +61 3 6232 3209 and DELETE the message. Visit our web site at http://www.antarctica.gov.au/ ___ [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] V2.9.0 changes [Sec=Unclassified]
Hi all,
Prefix: I am a frustrated Java coder in R.
I am coding a medium sized ecosystem modelling program in R. I have changed to
using S4 objects and it has cost me an order of magnitude in execution speed
over the functional model. I cannot afford this penalty and have found that it
is the result of all the passing-by-value of objects.
I see that you can now safely inherit from environment in V2.9.0.
That got me all excited that I would now be able to pass objects by reference.
But...
That doesn't seem to be the case.
It only seem that passing an environment which holds the object allows for
pass-by-reference and that passing an object which inherits from environment
doesn't.
Why is this the case, either an object inherits the properties of its parent or
it doesn't.
Has anyone else had a play with this? Or have I got it all wrong.
I tried the below:
-
setClass('foo', representation=representation(stuff='list', bar='numeric'),
prototype=list(stuff=list(), bar=0),
contains='.environment')
setGeneric('doit', function(.Object, newfoo='environment')
standardGeneric('doit'))
setMethod('doit', 'foo', function(.Object, newfoo){new...@bar <- 10})
z <- new('foo')
z...@stuff$x <- new('foo')
doit(z,z...@stuff$x)
z...@stuff$x@bar
[1] 0
--
Can anyone help with a better way of doing this.
I'm trying to avoid all the indirection of packing and unpacking environments
for passing.
Thanks heaps
Troy
Troy Robertson
Database and Computing Support Provider
Southern Ocean Ecosystems, ERM/Fish
Australian Antarctic Division
Channel Highway, Kingston 7050
PH: 03 62323571
troy.robert...@aad.gov.au
___
Australian Antarctic Division - Commonwealth of Australia
IMPORTANT: This transmission is intended for the addressee only. If you are not
the
intended recipient, you are notified that use or dissemination of this
communication is
strictly prohibited by Commonwealth law. If you have received this transmission
in error,
please notify the sender immediately by e-mail or by telephoning +61 3 6232
3209 and
DELETE the message.
Visit our web site at http://www.antarctica.gov.au/
___
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] V2.9.0 changes [Sec=Unclassified]
Yes, I had looked at R.oo, S4 and proto before beginning coding. I had
initially assumed that S4 was an enhancement of or replacement to R.oo that was
implemented at a lower level and had decided to go with the 'future' of OO in R.
These assumptions were not necessarily correct.
Troy
Troy Robertson
Database and Computing Support Provider
Southern Ocean Ecosystems, ERM/Fish
Australian Antarctic Division
Channel Highway, Kingston 7050
PH: 03 62323571
troy.robert...@aad.gov.au
> -Original Message-
> From: Antonio, Fabio Di Narzo [mailto:antonio.fa...@gmail.com]
> Sent: Tuesday, 23 June 2009 6:22 PM
> To: Troy Robertson
> Cc: r-devel@R-project.org
> Subject: Re: [Rd] V2.9.0 changes [Sec=Unclassified]
>
> Not a direct answer to your question, but...
> You might consider using the R.oo package, from H. Bengtsson. It's
> very stable, written in pure R, and cleanly allows you to do
> pass-by-reference OO programming, with no tricks.
>
> HTH,
> af
>
> 2009/6/23 Troy Robertson :
> > Hi all,
> >
> >
> >
> > Prefix: I am a frustrated Java coder in R.
> >
> >
> >
> > I am coding a medium sized ecosystem modelling program in R. I have
> changed to using S4 objects and it has cost me an order of magnitude in
> execution speed over the functional model. I cannot afford this penalty
> and have found that it is the result of all the passing-by-value of
> objects.
> >
> >
> >
> > I see that you can now safely inherit from environment in V2.9.0.
> >
> > That got me all excited that I would now be able to pass objects by
> reference.
> >
> >
> >
> > But...
> >
> > That doesn't seem to be the case.
> >
> > It only seem that passing an environment which holds the object allows
> for pass-by-reference and that passing an object which inherits from
> environment doesn't.
> >
> > Why is this the case, either an object inherits the properties of its
> parent or it doesn't.
> >
> > Has anyone else had a play with this? Or have I got it all wrong.
> >
> >
> >
> > I tried the below:
> >
> >
> -
> >
> > setClass('foo', representation=representation(stuff='list',
> bar='numeric'),
> >
> > prototype=list(stuff=list(), bar=0),
> >
> > contains='.environment')
> >
> >
> >
> > setGeneric('doit', function(.Object, newfoo='environment')
> standardGeneric('doit'))
> >
> >
> >
> > setMethod('doit', 'foo', function(.Object, newfoo){new...@bar <- 10})
> >
> >
> >
> > z <- new('foo')
> >
> >
> >
> > z...@stuff$x <- new('foo')
> >
> >
> >
> > doit(z,z...@stuff$x)
> >
> >
> >
> > z...@stuff$x@bar
> >
> >
> >
> > [1] 0
> >
> >
> --
> >
> >
> >
> > Can anyone help with a better way of doing this.
> >
> > I'm trying to avoid all the indirection of packing and unpacking
> environments for passing.
> >
> >
> >
> >
> >
> > Thanks heaps
> >
> >
> >
> > Troy
> >
> >
> >
> >
> >
> > Troy Robertson
> >
> > Database and Computing Support Provider
> >
> > Southern Ocean Ecosystems, ERM/Fish
> >
> > Australian Antarctic Division
> >
> > Channel Highway, Kingston 7050
> >
> > PH: 03 62323571
> >
> > troy.robert...@aad.gov.au
> >
> >
> >
> >
> >
> __
> _
> >
> >Australian Antarctic Division - Commonwealth of Australia
> > IMPORTANT: This transmission is intended for the addressee only. If you
> are not the
> > intended recipient, you are notified that use or dissemination of this
> communication is
> > strictly prohibited by Commonwealth law. If you have received this
> transmission in error,
> > please notify the sender immediately by e-mail or by telephoning +61 3
> 6232 3209 and
> > DELETE the message.
> >Visit our web site at http://www.antarctica.gov.au/
> >
> __
> _
> >
> >[[alternative HTML version delete
Re: [Rd] V2.9.0 changes [Sec=Unclassified]
Thanks Martin,
Yes I can see that a slot can be initialised as an environment, and data stored
within that environment but it seems to then require an additional layer of
indirection to access data members within the environment and negates the use
of slots in the first place.
The same goes for the "[[" function which works on an object which extends
environment as I would expect slots within that object to work (but don't), eg
allowing a pass-by-reference arrangement.
I hadn't encountered the use of .xdata as you demonstrated below and think I
can work with this way of assigning data members to an S4 object, allowing for
a pass-by-reference mechanism. It just seems to negate the point of providing
a slot mechanism for objects.
As for stepping back and re-thinking the way I am implementing my data
structures and methods. It is difficult coming from one way of coding in a
different language. It's easy to try and enforce that way of doing things on
the new language. Can you point me to any examples of general programming
using S4 that I could use to change my way of thinking about the problem?
I will have a play around more tomorrow.
Cheers
Troy
> -Original Message-
> From: Martin Morgan [mailto:mtmor...@fhcrc.org]
> Sent: Tuesday, 23 June 2009 11:25 PM
> To: Troy Robertson
> Cc: 'r-devel@R-project.org'
> Subject: Re: [Rd] V2.9.0 changes [Sec=Unclassified]
>
> Troy Robertson wrote:
> > Hi all,
> >
> >
> >
> > Prefix: I am a frustrated Java coder in R.
>
> ah good, if you're frustrated with Java you'll find R very different ;)
>
> >
> >
> >
> > I am coding a medium sized ecosystem modelling program in R. I have
> changed to using S4 objects and it has cost me an order of magnitude in
> execution speed over the functional model. I cannot afford this penalty
> and have found that it is the result of all the passing-by-value of
> objects.
> >
> >
> >
> > I see that you can now safely inherit from environment in V2.9.0.
> >
> > That got me all excited that I would now be able to pass objects by
> reference.
> >
> >
> >
> > But...
> >
> > That doesn't seem to be the case.
> >
> > It only seem that passing an environment which holds the object allows
> for pass-by-reference and that passing an object which inherits from
> environment doesn't.
> >
> > Why is this the case, either an object inherits the properties of its
> parent or it doesn't.
>
> The object inherits slots from it's parent, and the methods defined on
> the parent class. Maybe this example helps?
>
> setClass("Ticker", contains=".environment")
>
> ## initialize essential, so each instance gets its own environment
> setMethod(initialize, "Ticker",
> function(.Object, ..., .xData=new.env(parent=emptyenv()))
> {
> .xData[["count"]] <- 0
> callNextMethod(.Object, ..., .xData=.xData)
> })
>
> ## tick: increment (private) counter by n
> setGeneric("tick", function(reference, n=1L) standardGeneric("tick"),
>signature="reference")
>
> setMethod(tick, "Ticker", function(reference, n=1L) {
> reference[["count"]] <- reference[["count"]] + n
> })
>
> ## tock: report current value of counter
> setGeneric("tock", function(reference) standardGeneric("tock"))
>
> setMethod(tock, "Ticker", function(reference) {
> reference[["count"]]
> })
>
> and then
>
> > e <- new("Ticker")
> > tock(e)
> [1] 0
> > tick(e); tick(e, 10); tock(e)
> [1] 11
> > f <- e
> > tock(f); tick(e); tock(f)
> [1] 11
> [1] 12
>
> The data inside .environment could be structured, too, using S4.
> Probably it would be more appropriate to have the environment as a slot,
> rather the class that is being extended. And in terms of inherited
> 'properties', e.g., the "[[" function as defined on environments is
> available
>
> > e[["count"]]
>
> Of course I haven't seen your code, but a different interpretation of
> your performance issues is that, within the rules of S4, you've chosen
> to implement functionality in an inefficient way. So it might be
> instructive to step back a bit and try to reformulate your data
> structures and methods. This is hard to do.
>
> Martin
>
> >
> > Has anyone else had a play with this? Or have I got it all wrong.
> >
> >
&
[Rd] S4 and connection slot [Sec=Unclassified]
Hi all,
I am having a problem trying to declare a slot representation to hold a file
connection.
With V2.8.0 I had been using:
setClass("Element",
representation(
[other slots removed],
datafileConn= setOldClass(c("file","connection"))
)
)
This resulted in a warning but still ran okay.
No however with V2.9.0 I am getting an error:
Error in representation(state = "list", initialState = "list", polygons =
"list", :
element 12 of the representation was not a single character string
How can I declare a slot of the appropriate class? The strings "connection",
"file" fail.
Troy
Troy Robertson
Database and Computing Support Provider
Southern Ocean Ecosystems, ERM/Fish
Australian Antarctic Division
Channel Highway, Kingston 7050
PH: 03 62323571
troy.robert...@aad.gov.au
___
Australian Antarctic Division - Commonwealth of Australia
IMPORTANT: This transmission is intended for the addressee only. If you are not
the
intended recipient, you are notified that use or dissemination of this
communication is
strictly prohibited by Commonwealth law. If you have received this transmission
in error,
please notify the sender immediately by e-mail or by telephoning +61 3 6232
3209 and
DELETE the message.
Visit our web site at http://www.antarctica.gov.au/
___
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] S4 and connection slot [Sec=Unclassified]
Right you are Martin,
When you simplify things right down your code below works.
I had kept getting the error below:
Error in validObject(.Object) :
invalid class "KrillEnvironment" object: class for slot "datafileConn"
("file")
But now realise that it is when the class extends '.environment' and passes
through the .xData slot:
setClass("Element",representation=representation(datafileConn="file"),
contains=".environment")
setMethod("initialize", "Element",
function(.Object,.xData=new.env(parent=emptyenv())) {
.Object <- callNextMethod(.Object, .xData=.xData)
return(.Object)
}
)
s <- new("Element")
Not sure why that changes things though?
Troy
> -Original Message-
> From: Martin Morgan [mailto:mtmor...@fhcrc.org]
> Sent: Monday, 29 June 2009 2:21 PM
> To: Troy Robertson
> Subject: Re: [Rd] S4 and connection slot [Sec=Unclassified]
>
> Troy Robertson wrote:
> > Hi all,
> >
> >
> >
> > I am having a problem trying to declare a slot representation to hold a
> file connection.
> >
> > With V2.8.0 I had been using:
> >
> >
> >
> > setClass("Element",
> >
> > representation(
> >
> > [other slots removed],
> >
> > datafileConn= setOldClass(c("file","connection"))
> >
> > )
> >
> > )
> >
>
> I think
>
> setOldClass(c("file", "connection"))
>
> setClass("Element",
> representation=representation(datafileConn="file"))
>
> getClass("file")
> getClass("Element")
>
> but I don't usually use S3 classes so I'm not sure...
>
> Martin
>
> >
> >
> > This resulted in a warning but still ran okay.
> >
> >
> >
> > No however with V2.9.0 I am getting an error:
> >
> >
> >
> > Error in representation(state = "list", initialState = "list", polygons
> = "list", :
> >
> > element 12 of the representation was not a single character string
> >
> >
> >
> > How can I declare a slot of the appropriate class? The strings
> "connection", "file" fail.
> >
> >
> >
> > Troy
> >
> >
> >
> >
> >
> > Troy Robertson
> >
> > Database and Computing Support Provider
> >
> > Southern Ocean Ecosystems, ERM/Fish
> >
> > Australian Antarctic Division
> >
> > Channel Highway, Kingston 7050
> >
> > PH: 03 62323571
> >
> > troy.robert...@aad.gov.au
> >
> >
> >
> >
> >
> __
> _
> >
> > Australian Antarctic Division - Commonwealth of Australia
> > IMPORTANT: This transmission is intended for the addressee only. If you
> are not the
> > intended recipient, you are notified that use or dissemination of this
> communication is
> > strictly prohibited by Commonwealth law. If you have received this
> transmission in error,
> > please notify the sender immediately by e-mail or by telephoning +61 3
> 6232 3209 and
> > DELETE the message.
> > Visit our web site at http://www.antarctica.gov.au/
> >
> __
> _
> >
> > [[alternative HTML version deleted]]
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
___
Australian Antarctic Division - Commonwealth of Australia
IMPORTANT: This transmission is intended for the addressee only. If you are not
the
intended recipient, you are notified that use or dissemination of this
communication is
strictly prohibited by Commonwealth law. If you have received this transmission
in error,
please notify the sender immediately by e-mail or by telephoning +61 3 6232
3209 and
DELETE the message.
Visit our web site at http://www.antarctica.gov.au/
___
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] S4 and connection slot [Sec=Unclassified]
Thanks guys,
I wasn't having a problem storing active connections in slots initially. They
were opened during initialisation of the object and then a routine ran through
and closed them all before the program exited.
I have now implemented them as environment stored objects as a way around the
slot problem (along with all the rest of the class data members so that object
passing is more efficient without all the memcpying). So much for S4 slots.
Troy
> -Original Message-
> From: Martin Morgan [mailto:mtmor...@fhcrc.org]
> Sent: Tuesday, 30 June 2009 5:12 AM
> To: Stavros Macrakis
> Cc: Troy Robertson; r-devel@R-project.org
> Subject: Re: [Rd] S4 and connection slot [Sec=Unclassified]
>
> Stavros Macrakis wrote:
> > On Mon, Jun 29, 2009 at 9:19 AM, Martin Morgan > <mailto:mtmor...@fhcrc.org>> wrote:
> >
> > ...I'm not sure that including a connection in a slot is going to be
> > a good
> > idea, though -- a connection has reference-like semantics, so you
> can
> > end up with multiple objects pointing to the same connection, Also
> when
> > an object is garbage collected the connection will not be closed
> > automatically.
> >
> >
> > I'm not sure I understand your point here. Having multiple objects
> > refer to the same connection seems like a perfectly reasonable and
> > useful thing, and garbage collection should work just fine -- when *all*
> > of the objects referring to that connection are unreachable, then the
> > connection is unreachable and will itself be garbage collected. No?
>
> I meant that, in practice, there were enough additional pitfalls that I
> wouldn't choose this route (placing a connection in an S4 slot) for
> myself. These little experiments were enough to make me cautious...
>
> setOldClass(c("file", "connection"))
>
> ## Attempt one -- prototype
> setClass("Element",
> representation=representation(conn="file"),
> prototype=prototype(conn=file()))
>
> ## oops, all instances share a single connection
>
> close(new("Element")@conn)
> ## oops, all new instances now have a closed (invalid) connection
>
>
> ## Attempt two -- initialize
> setClass("Element",
> representation=representation(conn="file"))
>
> setMethod(initialize, "Element", function(.Object, ..., conn=file()) {
> callNextMethod(.Object, ..., conn=conn)
> })
>
> new("Element")
> ## oops, connection created but not closed; gc() closes (eventually)
> ## but with an ugly warning
> ## > gc()
> ##used (Mb) gc trigger (Mb) max used (Mb)
> ## Ncells 717240 38.41166886 62.4 1073225 57.4
> ## Vcells 3795 284.9 63274729 482.8 60051033 458.2
> ## > gc()
> ##used (Mb) gc trigger (Mb) max used (Mb)
> ## Ncells 715906 38.31166886 62.4 1073225 57.4
> ## Vcells 37335626 284.9 63274729 482.8 60051033 458.2
> ## Warning messages:
> ## 1: closing unused connection 3 ()
>
> setClass("ElementX", contains="Element")
> ## oops, two connections opened (!)
> ## > showConnections()
> ## description class mode text isopen can read can write
> ## 3 "" "file" "w+" "text" "opened" "yes""yes"
> ## 4 "" "file" "w+" "text" "opened" "yes""yes"
>
> And while completely expected the action-at-a-distance of references has
> the usual risks
>
> > x <- y <- new("Element")
> > close(x...@conn)
> > y
> An object of class "Element"
> Slot "conn":
> Error in summary.connection(x) : invalid connection
>
> One place I know where S4 and connections are used effectively is in the
> AnnotationDbi package in Bioconductor (I did not participate in
> developing this package, so am probably misrepresenting its
> implementation). Here there is a database connection. But it is stored
> in an environment in an S4 class. This part of the class is used
> essentially as a singleton -- AnnotationDbi creates packages containing
> instances, and users load the package and hence single instance; the
> interface never exposes the connection itself to copying. The database
> functionality exposed to the user is read-only, and querying the
> connection does not change it's state (other than opening it if it were
> closed). I think the underlying connection has C code to tidy itself up
> appropriately (and quietly) when eventually garbage collected. So yes,
Re: [Rd] V2.9.0 changes [Sec=Unclassified]
Well...
My performance problems were in the pass-by-value semantics of R.
I have just changed my classes to inherit from .environment and then moved data
members from S4 slots to the .xData objects as Martin suggested.
That meant I could remove all my returns and assignments on all method calls.
This has sped execution time for my model up by more than an order of
magnitude. Eg one test simulation from 1931 secs down to 175 secs.
Not bad seeing as though the class structure, functionality and logic has not
been touched.
I really do think S4 could benfit from having its slots stored in environment
when the class enherits from .environment. It would be a lot more sensible if
my data members were still declared as S4 slots instead of having to hide them
in .xData
Troy
Troy Robertson
Database and Computing Support Provider
Southern Ocean Ecosystems, ERM/Fish
Australian Antarctic Division
Channel Highway, Kingston 7050
PH: 03 62323571
troy.robert...@aad.gov.au
> -Original Message-
> From: Martin Morgan [mailto:mtmor...@fhcrc.org]
> Sent: Tuesday, 23 June 2009 11:25 PM
> To: Troy Robertson
> Cc: 'r-devel@R-project.org'
> Subject: Re: [Rd] V2.9.0 changes [Sec=Unclassified]
>
> Troy Robertson wrote:
> > Hi all,
> >
> >
> >
> > Prefix: I am a frustrated Java coder in R.
>
> ah good, if you're frustrated with Java you'll find R very different ;)
>
> >
> >
> >
> > I am coding a medium sized ecosystem modelling program in R. I have
> changed to using S4 objects and it has cost me an order of magnitude in
> execution speed over the functional model. I cannot afford this penalty
> and have found that it is the result of all the passing-by-value of
> objects.
> >
> >
> >
> > I see that you can now safely inherit from environment in V2.9.0.
> >
> > That got me all excited that I would now be able to pass objects by
> reference.
> >
> >
> >
> > But...
> >
> > That doesn't seem to be the case.
> >
> > It only seem that passing an environment which holds the object allows
> for pass-by-reference and that passing an object which inherits from
> environment doesn't.
> >
> > Why is this the case, either an object inherits the properties of its
> parent or it doesn't.
>
> The object inherits slots from it's parent, and the methods defined on
> the parent class. Maybe this example helps?
>
> setClass("Ticker", contains=".environment")
>
> ## initialize essential, so each instance gets its own environment
> setMethod(initialize, "Ticker",
> function(.Object, ..., .xData=new.env(parent=emptyenv()))
> {
> .xData[["count"]] <- 0
> callNextMethod(.Object, ..., .xData=.xData)
> })
>
> ## tick: increment (private) counter by n
> setGeneric("tick", function(reference, n=1L) standardGeneric("tick"),
>signature="reference")
>
> setMethod(tick, "Ticker", function(reference, n=1L) {
> reference[["count"]] <- reference[["count"]] + n
> })
>
> ## tock: report current value of counter
> setGeneric("tock", function(reference) standardGeneric("tock"))
>
> setMethod(tock, "Ticker", function(reference) {
> reference[["count"]]
> })
>
> and then
>
> > e <- new("Ticker")
> > tock(e)
> [1] 0
> > tick(e); tick(e, 10); tock(e)
> [1] 11
> > f <- e
> > tock(f); tick(e); tock(f)
> [1] 11
> [1] 12
>
> The data inside .environment could be structured, too, using S4.
> Probably it would be more appropriate to have the environment as a slot,
> rather the class that is being extended. And in terms of inherited
> 'properties', e.g., the "[[" function as defined on environments is
> available
>
> > e[["count"]]
>
> Of course I haven't seen your code, but a different interpretation of
> your performance issues is that, within the rules of S4, you've chosen
> to implement functionality in an inefficient way. So it might be
> instructive to step back a bit and try to reformulate your data
> structures and methods. This is hard to do.
>
> Martin
>
> >
> > Has anyone else had a play with this? Or have I got it all wrong.
> >
> >
> >
> > I tried the below:
> >
> >
> -
> >
> > setClass('foo', representation=representation(stuff='list',
> bar='numeric'),
> >
> >
Re: [Rd] V2.9.0 changes [Sec=Unclassified]
> -Original Message-
> From: Martin Morgan [mailto:mtmor...@fhcrc.org]
> Sent: Thursday, 2 July 2009 10:58 PM
> To: Troy Robertson
> Cc: 'r-devel@R-project.org'
> Subject: Re: [Rd] V2.9.0 changes [Sec=Unclassified]
>
> Troy Robertson wrote:
> > Well...
> >
> > My performance problems were in the pass-by-value semantics of R.
> >
> > I have just changed my classes to inherit from .environment and then
> moved data members from S4 slots to the .xData objects as Martin
> suggested.
>
> Actually, I had hoped the take-home message would be in the final
> paragraph:
>
> >> Of course I haven't seen your code, but a different interpretation of
> >> your performance issues is that, within the rules of S4, you've chosen
> >> to implement functionality in an inefficient way. So it might be
> >> instructive to step back a bit and try to reformulate your data
> >> structures and methods. This is hard to do.
>
Yes, it just takes a little time and playing around to work out the rules of R
(and S4) though, and how to use them to your advantage rather than be limited
by them. I know I am still probably not using this functional language in the
best way, but there you go.
>
> > That meant I could remove all my returns and assignments on all method
> calls.
> >
> > This has sped execution time for my model up by more than an order of
> magnitude. Eg one test simulation from 1931 secs down to 175 secs.
> >
> > Not bad seeing as though the class structure, functionality and logic
> has not been touched.
> >
> > I really do think S4 could benfit from having its slots stored in
> environment when the class enherits from .environment. It would be a lot
> more sensible if my data members were still declared as S4 slots instead
> of having to hide them in .xData
> >
> > Troy
> >
> >
> > Troy Robertson
> > Database and Computing Support Provider
> > Southern Ocean Ecosystems, ERM/Fish
> > Australian Antarctic Division
> > Channel Highway, Kingston 7050
> > PH: 03 62323571
> > troy.robert...@aad.gov.au
> >
> >
> >> -Original Message-
> >> From: Martin Morgan [mailto:mtmor...@fhcrc.org]
> >> Sent: Tuesday, 23 June 2009 11:25 PM
> >> To: Troy Robertson
> >> Cc: 'r-devel@R-project.org'
> >> Subject: Re: [Rd] V2.9.0 changes [Sec=Unclassified]
> >>
> >> Troy Robertson wrote:
> >>> Hi all,
> >>>
> >>>
> >>>
> >>> Prefix: I am a frustrated Java coder in R.
> >> ah good, if you're frustrated with Java you'll find R very different ;)
> >>
> >>>
> >>>
> >>> I am coding a medium sized ecosystem modelling program in R. I have
> >> changed to using S4 objects and it has cost me an order of magnitude in
> >> execution speed over the functional model. I cannot afford this
> penalty
> >> and have found that it is the result of all the passing-by-value of
> >> objects.
> >>>
> >>>
> >>> I see that you can now safely inherit from environment in V2.9.0.
> >>>
> >>> That got me all excited that I would now be able to pass objects by
> >> reference.
> >>>
> >>>
> >>> But...
> >>>
> >>> That doesn't seem to be the case.
> >>>
> >>> It only seem that passing an environment which holds the object allows
> >> for pass-by-reference and that passing an object which inherits from
> >> environment doesn't.
> >>> Why is this the case, either an object inherits the properties of its
> >> parent or it doesn't.
> >>
> >> The object inherits slots from it's parent, and the methods defined on
> >> the parent class. Maybe this example helps?
> >>
> >> setClass("Ticker", contains=".environment")
> >>
> >> ## initialize essential, so each instance gets its own environment
> >> setMethod(initialize, "Ticker",
> >> function(.Object, ..., .xData=new.env(parent=emptyenv()))
> >> {
> >> .xData[["count"]] <- 0
> >> callNextMethod(.Object, ..., .xData=.xData)
> >> })
> >>
> >> ## tick: increment (private) counter by n
> >> setGeneric("tick", function(reference, n=1L) standardGeneric("tick"),
> >>signature="reference")
> >>
> >> setMethod(tick, "Ticke
Re: [Rd] OOP performance, was: V2.9.0 changes [SEC=Unclassified]
Hi Thomas, It is a population-based model, but I didn't develop the work. I am just the programmer who has been given the job of coding it. The goal is to allow for a plug and play type approach by users to construction of the model (of both elements and functionality). Hence my focus on OO. You are right about avoiding the copying of large objects. That is what was killing things. I am now working on vectorizing more of the number crunching and removing some of the nested for loops. That should step things up a little too. I do also need to investigate how to move some of the more expensive code to C. Had a quick look at simecol which looks interesting. Will point it out to my boss to check out too. Thanks Troy > -Original Message- > From: Thomas Petzoldt [mailto:thomas.petzo...@tu-dresden.de] > Sent: Friday, 3 July 2009 1:31 AM > To: Troy Robertson > Cc: 'r-devel@R-project.org' > Subject: OOP performance, was: [Rd] V2.9.0 changes [SEC=Unclassified] > > Hi Troy, > > first of all a question, what kind of ecosystem models are you > developing in R? Differential equations or individual-based? > > Your write that you are a frustrated Java developer in R. I have a > similar experience, however I still like JAVA, and I'm now more happy > with R as it is much more efficient (i.e. sum(programming + runtime)) > for the things I usually do: ecological data analysis and modelling. > > After using functional R quite a time and Java in parallel > I had the same idea, to make R more JAVA like and to model ecosystems in > an object oriented manner. At that time I took a look into R.oo (thanks > Henrik Bengtssson) and was one of the Co-authors of proto. I still think > that R.oo is very good and that proto is a cool idea, but finally I > switched to the recommended S4 for my ecological simulation package. > > Note also, that my solution was *not* to model the ecosystems as objects > (habitat - populations- individuals), but instead to model ecological > models (equations, inputs, parameters, time steps, outputs, ...). > > This works quite well with S4. A speed test (see useR!2006 poster on > http://simecol.r-forge.r-project.org/) showed that all OOP flavours had > quite comparable performance. > > The only thing I have to have in mind are a few rules: > > - avoid unnecessary copying of large objects. Sometimes it helps to > prefer matrices over data frames. > > - use vectorization. This means for an individual-based model that one > has to re-think how to model an individual: not "many [S4] objects" > like in JAVA, but R structures (arrays, lists, data frames) where > vectorized functions (e.g. arithmetics or subset) can work with. > > - avoid interpolation (i.e. approx) and if unavoidable, minimize the > tables. > > If all these things do not help, I write core functions in C (others use > Fortran). This can be done in a mixed style and even a full C to C > communication is possible (see the deSolve documentation how to do this > with differential equation models). > > > Thomas P. > > > > -- > Thomas Petzoldt > Technische Universitaet Dresden > Institut fuer Hydrobiologiethomas.petzo...@tu-dresden.de > 01062 Dresden http://tu-dresden.de/hydrobiologie/ > GERMANY > > > > ___ Australian Antarctic Division - Commonwealth of Australia IMPORTANT: This transmission is intended for the addressee only. If you are not the intended recipient, you are notified that use or dissemination of this communication is strictly prohibited by Commonwealth law. If you have received this transmission in error, please notify the sender immediately by e-mail or by telephoning +61 3 6232 3209 and DELETE the message. Visit our web site at http://www.antarctica.gov.au/ ___ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] OOP performance, was: V2.9.0 changes [SEC=Unclassified]
Hi Gabor, Look, I agree with you about S3 and have at times wished I had chosen that path rather than S4. It seems to do the things I struggle to find answers for with S4. But..., knowing little about R before engaging with this project, I decided to go with the latest OO framework, S4. I do now find that I am undoing some of it, such as the use of data member slots, in order to implement pass-by-ref via environments and improve performance. But its all a learning experience. Troy > -Original Message- > From: Gabor Grothendieck [mailto:ggrothendi...@gmail.com] > Sent: Friday, 3 July 2009 10:29 AM > To: Troy Robertson; r-devel@R-project.org > Subject: Re: [Rd] OOP performance, was: V2.9.0 changes [SEC=Unclassified] > > In terms of performance if you want the fastest > performance in R go with S3 and if you want > even faster performance rewrite your inner loops > in C. All the other approaches will usually be slower. > Also S3 is simple, elegant and will result in less code > and take you much less time to design, program and > debug. > > For 100% R code, particularly for simulations, > proto can sometimes be even faster than pure R code based > S3 as proto supports hand optimizations that cannot readily > be done in other systems. (For unoptimized code it would > be slower.) The key trick is based on its ability > to separate dispatching from calling so that if method f and > object p are unchanged in a loop >for(...) p$f(...) > then the loop can be rewritten > f <- p$f; for(...) f(...) > Note that this still retains dynamic dispatch but > just factors it out of the loop. With S3 the best you could > get would be for(...) f.p(...) where f is a method of class p > but this is really tantamount to not using OO at all since > no dispatch is done at all. > > On Thu, Jul 2, 2009 at 11:31 AM, Thomas > Petzoldt wrote: > > Hi Troy, > > > > first of all a question, what kind of ecosystem models are you > > developing in R? Differential equations or individual-based? > > > > Your write that you are a frustrated Java developer in R. I have a > > similar experience, however I still like JAVA, and I'm now more happy > > with R as it is much more efficient (i.e. sum(programming + runtime)) > > for the things I usually do: ecological data analysis and modelling. > > > > After using functional R quite a time and Java in parallel > > I had the same idea, to make R more JAVA like and to model ecosystems in > > an object oriented manner. At that time I took a look into R.oo (thanks > > Henrik Bengtssson) and was one of the Co-authors of proto. I still think > > that R.oo is very good and that proto is a cool idea, but finally I > > switched to the recommended S4 for my ecological simulation package. > > > > Note also, that my solution was *not* to model the ecosystems as objects > > (habitat - populations- individuals), but instead to model ecological > > models (equations, inputs, parameters, time steps, outputs, ...). > > > > This works quite well with S4. A speed test (see useR!2006 poster on > > http://simecol.r-forge.r-project.org/) showed that all OOP flavours had > > quite comparable performance. > > > > The only thing I have to have in mind are a few rules: > > > > - avoid unnecessary copying of large objects. Sometimes it helps to > > prefer matrices over data frames. > > > > - use vectorization. This means for an individual-based model that one > > has to re-think how to model an individual: not "many [S4] objects" > > like in JAVA, but R structures (arrays, lists, data frames) where > > vectorized functions (e.g. arithmetics or subset) can work with. > > > > - avoid interpolation (i.e. approx) and if unavoidable, minimize the > tables. > > > > If all these things do not help, I write core functions in C (others use > > Fortran). This can be done in a mixed style and even a full C to C > > communication is possible (see the deSolve documentation how to do this > > with differential equation models). > > > > > > Thomas P. > > > > > > > > -- > > Thomas Petzoldt > > Technische Universitaet Dresden > > Institut fuer Hydrobiologiethomas.petzo...@tu-dresden.de > > 01062 Dresden http://tu-dresden.de/hydrobiologie/ > > GERMANY > > > > __ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > ___ Australian Antarctic D
