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.
> >
> >
> >
> > 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
> >
> >
> --
> >
Re: [Rd] V2.9.0 changes [Sec=Unclassified]
> "TR" == Troy Robertson
> on Wed, 24 Jun 2009 16:35:29 +1000 writes:
TR> 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.
TR> These assumptions were not necessarily correct.
>From the view of the R core team,
S4 *is* ``the future of OO in R''
But then, as professional statisticians, we should consider the
famous
>>> Prediction is very difficult, especially about the future <<
attributed to Physics Nobel Prize winner Niels Bohr.
---
Martin Maechler, ETH Zurich & R-core
TR> Troy
TR> Troy Robertson
TR> Database and Computing Support Provider
TR> Southern Ocean Ecosystems, ERM/Fish
TR> Australian Antarctic Division
TR> Channel Highway, Kingston 7050
TR> PH: 03 62323571
TR> 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
>> >
..
>> --
>> Antonio, Fabio Di Narzo
>> Ph.D. student at
>> Department of Statistical Sciences
>> University of Bologna, Italy
TR>
___
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Documentation/software inconsistency in `:` and seq
Hi Stavros,
> "SM" == Stavros Macrakis
> on Tue, 23 Jun 2009 15:53:30 -0400 writes:
SM> In 2.8.1/Windows:
SM> According to ? :
SM> Details:
SM> For numeric arguments 'from:to' is equivalent to 'seq(from, to)' ...
that *is* definitely true asseq(from,to) leads to return(from:to)
SM> Value:
SM> For numeric arguments, a numeric vector. This will be of type
SM> 'integer' if 'from' and 'to' are both integers and representable
SM> in the integer type, otherwise of type 'numeric'
SM> The first claim is inconsistent with the second; it appears that the
first
SM> one is true and the second is false.
{1st, 2nd ... where do you start counting ?}
SM> Actual behavior:
SM> storage.mode(1:2.5) => integer
SM> storage.mode(`:`(from=1L,to=2.5)) => integer # just to be completely
SM> explicit
SM> But of course 2.5 is not an integer or equal to one.
Interestingly, because of an earlier posting on the topic,
two days ago (*), I have fixed the help page (and very slightly also
the code) of ":"
[for R-devel (to be 2.10.0 in October) only, because R 2.9.1
has already been in pre-release feature deep freeze ].
SM> This is the same behavior as seq:
SM> storage.mode(seq(1,2.5)) => integer
SM> storage.mode(seq(from=1L,to=2.5)) => integer
{of course, as I mentioned above}
SM> -
SM> On the other hand, according to ? seq
SM> Currently, the default method returns a result of type '"integer"'
SM> if 'from' is (numerically equal to an) integer
SM> This is not correct:
Yes, seq(from, to) {without further arguments} and "default"
'from', indeed returns from:to
and hence should probably either defer to the ":" help page
or copy-paste from it.
Martin Maechler, ETH Zurich
(*)
r48823 | maechler | 2009-06-22 17:57:05 +0200 (Mon, 22 Jun 2009)
Improve doc of ":" {and code very slightly, at the boundary of MAX_INT}
>> seq(1e16,1e16+10)
SM> [1] 1e+16 1e+16 1e+16 1e+16 1e+16 1e+16 1e+16 1e+16 1e+16 1e+16 1e+16
>> seq(1e16,1e16+10)-1e16
SM> [1] 0 0 2 4 4 4 6 8 8 8 10 # not enough precision to
represent
SM> all the distinct integers, OK
>> storage.mode(seq(1e16,1e16+10))
SM> [1] "double"
SM> In this case, the ? : documentation is correct:
SM> This will be of type 'integer' if ... representable in the integer
SM> type, otherwise of type 'numeric'.
SM> [[alternative HTML version deleted]]
{I'm amazed that you still did not find out how to avoid the
above, e.g., by following the posting guide ...}
SM> __
SM> R-devel@r-project.org mailing list
SM> 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] V2.9.0 changes [Sec=Unclassified]
Martin Maechler wrote: > > But then, as professional statisticians, we should consider the > famous >>>> Prediction is very difficult, especially about the future << > attributed to Physics Nobel Prize winner Niels Bohr. ...and quotations are even more difficult! A number of people are known NOT to be the source of that one, including Bohr, Robert Storm Petersen, and former minister of culture Steincke (in his memoirs, he mentions it being used in parliament some time during 1935--1939, but he forgot by whom). One source has "Markus M. Ronner, and others" (he was born in 1938, though!) -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - (p.dalga...@biostat.ku.dk) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] loadNamespace and useDynLib
Kasper Daniel Hansen wrote: I am considering a package with a namespace (Rgraphviz from Bioc). I essentially want to have some error handling for loading the dll, something like wrapping it into tryCatch or similar (reason: see below). Right now I am loading the dynamic libraries by useDynLib in my NAMESPACE file. When I look at the code from loadNamespace, I have the impression that what I want is impossible (.onLoad and the user settable hooks are called after the dynamic libraries have been loaded). Is that true? And is the only way to proceed, to not use useDynLib in my NAMESPACE file, but instead load the dynamic libraries manually in .onLoad? Reason for my wish: on Windows Rgraphviz links to Graphviz which the user needs to install themselves. Unfortunately there are many versions of Graphviz and they tend to be incompatible with each other, to the extent that certain libraries have been renamed. This has been causing a lot of confusion since the Windows binaries have been compiled with one specific version, and sometimes the loading of the dll itself fails because the libraries have been renamed I am attempting to inject some kind of helpful error message along the lines of "it looks like you did not have version XXX of Graphviz installed". For that to happen, I need to do a tryCatch. There is a potential similar problem for binaries on OS X (but somewhat fewer complaints). At first, I do not answer your question, but make your request more complicated: It is even hard to find "version XXX of Graphviz", because the numbers in the names of the distributed graphviz zip files and the actual versions of graphviz are also not always the same. Beside that the graphviz folks obviously even change API specifications in patch-level releases. Then to your question: I think your are right and need it in .onLoad where you can finally check if the dll has been loaded and generate erro messages. Good luck, Uwe I could see the use for this for other packages that depends on external DLLs. Thanks Kasper __ 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] loadNamespace and useDynLib
I've also experienced this problem with RGraphviz and suggest you expand the message to: Graphviz version x found at c:\...whatever...\graphviz.dll but version y found at http://whatever required. Another approach would be to check that the file size, file name, checksum or some other attribute of the needed version matches the version found. That way you could give the error message before loading the dll. A third approach would be to provide an R command that downloads and installs the correct version of graphviz to reduce the possibility of error in the first place. The user must be connected to the internet for that to work. For example, in Ryacas, if yacas itself is not located when the package loads a message is given to run the command: yacasInstall() Running that command from within R downloads the correct yacas*.zip file, unpacks it and installs the components. See: http://ryacas.googlecode.com/svn/trunk/R/yacasInstall.R http://ryacas.googlecode.com/svn/trunk/man/yacasInstall.Rd That won't prevent the wrong version from being used but it makes it much less likely. On Wed, Jun 24, 2009 at 1:46 AM, Kasper Daniel Hansen wrote: > I am considering a package with a namespace (Rgraphviz from Bioc). I > essentially want to have some error handling for loading the dll, something > like wrapping it into tryCatch or similar (reason: see below). Right now I > am loading the dynamic libraries by useDynLib in my NAMESPACE file. When I > look at the code from loadNamespace, I have the impression that what I want > is impossible (.onLoad and the user settable hooks are called after the > dynamic libraries have been loaded). Is that true? And is the only way to > proceed, to not use useDynLib in my NAMESPACE file, but instead load the > dynamic libraries manually in .onLoad? > > Reason for my wish: on Windows Rgraphviz links to Graphviz which the user > needs to install themselves. Unfortunately there are many versions of > Graphviz and they tend to be incompatible with each other, to the extent > that certain libraries have been renamed. This has been causing a lot of > confusion since the Windows binaries have been compiled with one specific > version, and sometimes the loading of the dll itself fails because the > libraries have been renamed I am attempting to inject some kind of > helpful error message along the lines of "it looks like you did not have > version XXX of Graphviz installed". For that to happen, I need to do a > tryCatch. There is a potential similar problem for binaries on OS X (but > somewhat fewer complaints). > > I could see the use for this for other packages that depends on external > DLLs. > > Thanks > Kasper > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Quotations (was Re: V2.9.0 changes [Sec=Unclassified])
Also attributed (incorrectly) to both Yogi Berra and Mark Twain. The Twain attribution leads (because he published numerous essays and short stories in The Galaxy magazine) to one possible (and documentable) source: "[I]f we found a character in a novel represented as habitually uttering true predictions of the future, we should cry out at once against the improbability." – Charles Astor Bristed (aka Carl Benson), Casual Cogitations, The Galaxy, 1873; 16:196–201. Peter Dalgaard wrote: Martin Maechler wrote: But then, as professional statisticians, we should consider the famous >>> Prediction is very difficult, especially about the future << attributed to Physics Nobel Prize winner Niels Bohr. ...and quotations are even more difficult! A number of people are known NOT to be the source of that one, including Bohr, Robert Storm Petersen, and former minister of culture Steincke (in his memoirs, he mentions it being used in parliament some time during 1935--1939, but he forgot by whom). One source has "Markus M. Ronner, and others" (he was born in 1938, though!) __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Documentation/software inconsistency in `:` and seq
On Wed, Jun 24, 2009 at 5:28 AM, Martin Maechler
wrote:
>
> SM> But of course 2.5 is not an integer or equal to one.
>
> Interestingly, because of an earlier posting on the topic,
> two days ago (*), I have fixed the help page (and very slightly also
> the code) of ":"
Sorry for the redundant report -- I don't remember that post.
>
> SM> Currently, the default method returns a result of type '"integer"'
> SM> if 'from' is (numerically equal to an) integer
>
> SM> This is not correct:
>
> Yes, seq(from, to) {without further arguments} and "default" 'from', indeed
> returns from:to
> and hence should probably either defer to the ":" help page or copy-paste
> from it.
Agreed.
>
> SM> [[alternative HTML version deleted]]
>
>
> {I'm amazed that you still did not find out how to avoid the
> above, e.g., by following the posting guide ...}
I'm amazed you haven't upgraded from your ASR-33 with acoustic coupler :-)
-s
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] RGui Configuration editor crashes when using an unlisted font (PR#13780)
Full_Name: Richard Cotton Version: 2.9.0 OS: Windows XP, SP2, 32 bit Submission from: (NULL) (87.102.99.18) To reproduce the crash: 1. Create an RConsole file for your user account. 2. Close R. 3. Manually edit the font line to include a font that is not on the standard list of available fonts, e.g. font = Verdana 4. Open R. (At this point the console text should appear in the new font you have chosen.) 5. Click Edit -> Gui preferences to open the RGui Configuration Editor. R will now crash. I have reproduced this using the names of several different fonts in the RConsole file, and on several WinXP boxes. I also tried contacting the R-Devel list [1] to see if the problem extends to other OSes, though there has been no response so far. [1] http://www.nabble.com/RGui-Configuration-Editor-crashes-when-using-an-unlisted-font-td24111311.html __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Matrix vignette error in June 24 RC
I am getting the following problem with make check-all on the June 24
rc. I realize I could probably fix it by installing/setting a path to
the sty file, but I don't remember having to do that for make check-all
in the past.
Paul Gilbert
___
checking package 'Matrix'
* checking for working pdflatex ... OK
* using log directory '/home/paul/toolchain/R/src/R-rc/tests/Matrix.Rcheck'
* using R version 2.9.1 RC (2009-06-22 r48830)
* using session charset: UTF-8
* checking for file 'Matrix/DESCRIPTION' ... OK
* this is package 'Matrix' version '0.999375-29'
* checking package name space information ... OK
* checking package dependencies ... OK
* checking if this is a source package ... OK
* checking for executable files ... OK
* skipping installation test
* checking package directory ... OK
* checking for portable file names ... OK
* checking for sufficient/correct file permissions ... OK
* checking DESCRIPTION meta-information ... OK
* checking top-level files ... OK
* checking index information ... OK
* checking package subdirectories ... OK
* checking R files for non-ASCII characters ... OK
* checking R files for syntax errors ... OK
* checking whether the package can be loaded ... OK
* checking whether the package can be loaded with stated dependencies
OK
* checking whether the name space can be loaded with stated dependencies
OK
* checking for unstated dependencies in R code ... OK
* checking S3 generic/method consistency ... OK
* checking replacement functions ... OK
* checking foreign function calls ... OK
* checking R code for possible problems ... NOTE
graph.has.weights: no visible global function definition for
‘edgeDataDefaults’
graph.wgtMatrix: no visible global function definition for ‘numEdges’
graph.wgtMatrix: no visible global function definition for ‘nodes’
graph.wgtMatrix: no visible global function definition for
‘edgeDataDefaults’
graph.wgtMatrix: no visible global function definition for ‘edgeData’
Tsp2grNEL: no visible global function definition for ‘ftM2graphNEL’
coerce,graphAM-sparseMatrix: no visible global function definition for
‘edgemode’
coerce,graphNEL-TsparseMatrix: no visible global function definition
for ‘nodes’
coerce,graphNEL-TsparseMatrix: no visible global function definition
for ‘edgemode’
coerce,graphNEL-TsparseMatrix: no visible global function definition
for ‘edgeWeights’
Logic,ltCMatrix-ltCMatrix: no visible global function definition for
‘forceTriangular’
* checking Rd files ... OK
* checking Rd files against version 2 parser ... OK
* checking Rd cross-references ... OK
* checking for missing documentation entries ... OK
* checking for code/documentation mismatches ... OK
* checking Rd \usage sections ... OK
* checking data for non-ASCII characters ... OK
* checking line endings in C/C++/Fortran sources/headers ... OK
* checking line endings in Makefiles ... OK
* checking for portable compilation flags in Makevars ... OK
* checking for portable use of $BLAS_LIBS ... OK
* checking examples ... OK
* checking tests ...
Running ‘base-matrix-fun.R’
Running ‘bind.R’
Comparing ‘bind.Rout’ to ‘bind.Rout.save’ ... OK
Running ‘Class+Meth.R’
Running ‘dg_Matrix.R’
Running ‘dpo-test.R’
Running ‘dtpMatrix.R’
Running ‘factorizing.R’
Running ‘group-methods.R’
Running ‘indexing.R’
Comparing ‘indexing.Rout’ to ‘indexing.Rout.save’ ... OK
Running ‘matprod.R’
Running ‘matr-exp.R’
Running ‘other-pkgs.R’
Running ‘Simple.R’
Running ‘validObj.R’
Running ‘write-read.R’
OK
* checking package vignettes in 'inst/doc' ... NOTE
*** PDFLaTeX Errors ***
File
/home/paul/toolchain/R/src/R-rc/tests/Matrix.Rcheck/inst/doc/Intro2Matrix.Rnw
:
Running 'texi2dvi' on 'Intro2Matrix.tex' failed.
LaTeX errors:
! LaTeX Error: File `fullpage.sty' not found.
Type X to quit or to proceed,
or enter new name. (Default extension: sty)
! Emergency stop.
l.5 \usepackage
[authoryear,round]{natbib}^^M
! ==> Fatal error occurred, no output PDF file produced!
File
/home/paul/toolchain/R/src/R-rc/tests/Matrix.Rcheck/inst/doc/sparseModels.Rnw
:
Running 'texi2dvi' on 'sparseModels.tex' failed.
LaTeX errors:
! LaTeX Error: File `fullpage.sty' not found.
Type X to quit or to proceed,
or enter new name. (Default extension: sty)
! Emergency stop.
l.4 \usepackage
{myVignette}^^M
! ==> Fatal error occurred, no output PDF file produced!
* checking PDF version of manual ... OK
make[1]: Leaving directory `/home/paul/toolchain/R/src/R-rc/tests'
p...@dualx:~/toolchain/R/src/R-rc$
La version française suit le texte anglais.
This email may contain privileged and/or confidential in...{{dropped:26}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] V2.9.0 changes [Sec=Unclassified]
On Wed, Jun 24, 2009 at 4:27 AM, Martin
Maechler wrote:
>> "TR" == Troy Robertson
>> on Wed, 24 Jun 2009 16:35:29 +1000 writes:
>
> TR> 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.
> TR> These assumptions were not necessarily correct.
>
> >From the view of the R core team,
> S4 *is* ``the future of OO in R''
...and until we're there, R.oo (S3) will do it for you.
/Henrik
>
> But then, as professional statisticians, we should consider the
> famous
> >>> Prediction is very difficult, especially about the future <<
> attributed to Physics Nobel Prize winner Niels Bohr.
>
> ---
>
> Martin Maechler, ETH Zurich & R-core
>
>
> TR> Troy
>
> TR> Troy Robertson
> TR> Database and Computing Support Provider
> TR> Southern Ocean Ecosystems, ERM/Fish
> TR> Australian Antarctic Division
> TR> Channel Highway, Kingston 7050
> TR> PH: 03 62323571
> TR> 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
> >> >
>
> ..
>
>
> >> --
> >> Antonio, Fabio Di Narzo
> >> Ph.D. student at
> >> Department of Statistical Sciences
> >> University of Bologna, Italy
> TR>
> ___
>
> __
> 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
