Re: [Rd] tag \href not recognised in rd doc
On 11-06-06 12:41 AM, Patrick Giraudoux wrote:
Le 05/06/2011 22:30, Duncan Murdoch a écrit :
I don't get any error when I insert that code into a .Rd file in R
2.13.0 patched. The NEWS file says this was fixed in 2.12.2 patched.
What version are you using?
Duncan Murdoch
Currently R version 2.12.2 (2011-02-25) binary
Suppose I should move to the 2.13.0 ?
Yes, please do.
Duncan Murdoch
Patrick
On 11-06-05 10:56 AM, Patrick Giraudoux wrote:
Hi,
I have a trouble trying to use \href in a rd doc. See example below:
\references{
\href{http://www.ncbi.nlm.nih.gov/pmc/articles/PMC2702787/}{Vaniscotte
A., Pleydell D., Raoul F., Quere J.P., Coeurdassier M., Delattre P., Li
T., Qian W., Takahashi K., Weidmann J.C., Qiu J., Giraudoux P. 2009
Modelling and spatial discrimination of small mammal assemblages: an
example from western Sichuan (China). Ecological Modelling, 220:
1218-1231.}
}
The Rcmd check gives:
* checking R code for possible problems ... OK
* checking Rd files ... WARNING
checkRd: (7) multignome.Rd:38: Tag \href not recognized
I saw there is already a link on the issue
http://bugs.r-project.org/bugzilla3/show_bug.cgi?id=14535, but I hardly
understand if it is a real bug, if so if it have been fixed, or if I am
misusing the tag...
Any hint appreciated,
Best,
Patrick
__
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] Overloading S4 methods
On Wed, Jun 1, 2011 at 6:04 PM, Martin Morgan wrote:
> On 06/01/2011 04:39 AM, Iago Mosqueira wrote:
>>
>> Dear all,
>>
>> I am experiencing some problems with S4 method overloading. I have
>> defined a generic for graphics:plot, using
>>
>> setGeneric("plot", useAsDefault = plot)
>>
>> and with
>>
>> importFrom('graphics', 'plot') and
>>
>> exportMethods('plot') in the NAMESPACE file of pkg A.
>
> I'd guess you were creating two generics (explicitly in pkgA, implicitly in
> pkgB). Maybe
>
> export(plot)
>
> in NAMESPACE of pkg A,
>
> importFrom('pkgA', plot)
> exportMethods(plot)
>
> in pkg B. Feel free to post to the list if that's helpful.
>
> Martin
>
>>
>> I then proceed to define a method for signature c('myS4class',
>> 'missing'). This works as expected: selectMethod('plot',
>> c('myS4class', 'missing')) returns the newly defined method, and the
>> method gets called when invoked.
>>
>> Another pkg, B, wishes to overload this and redefines the method for
>> the same signature. A method is defined for c('myS4class', 'missing'),
>> and exported on the NAMESPACE. The new method is shown by
>> selectMethod() after pkg B has been loaded, but a call to
>>
>> plot(anobjectofmyS4class)
>>
>> comes up with the result of running the first method, from pkg A. I
>> have tried importing 'plot' in B's NAMESPACE from both graphics or A,
>> but the end result is the same.
>>
>> Package B does the same thing for a method created by pkg A, myMethod,
>> and that works fine.
>>
>> Any pointers or where this might be going wrong? How is it that a
>> different method than the one shown by selectMethod() is being run?
>> Something to do with the 'missing' part of the signature?
>>
>> Many thanks,
>>
>>
>>
>> Iago Mosqueira
Dear all,
I have tried Martin's suggestion, but the problem persists. It seems
to be related to having 'missing' in the signature, as doing the same
kind of overloading for c('myclass', 'ANY') work as expected.
I am attaching 2 simple packages where I attempt this repeated
overloading of plot for the same class. Script below, also found in
Bpkg/tests.test.R, shows what I have encountered so far:
plot('myclass', 'ANY') can be re-overloaded, but plot('myclass',
'missing') cannot in the same way. If I run
trace("plot", browser, exit=browser, signature = c("mynum", "missing"))
the new method is actually called.
Any hint on what I am doing wrong or where to look for an explanation
will be much appreciated.
Best regards,
Iago Mosqueira
plot_pkgs.tar.gz
Description: GNU Zip compressed data
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Interfacing a C++ class
Le 04/06/11 16:31, soeren.vo...@uzh.ch a écrit :
Hello
Apologies for cross-posting, the discussion should (if) go to R-devel, but I
also want to reach the rcpp-devel people.
My C++ class FOO is a module available through Rcpp, and it works fine and is
-- so far -- bug free. With trying to further develop my R package, I thought
it was a good idea to interface my C++ workhorse FOO with an S4 class Foo.
After some long and not always insightful trip through S4 classes and methods,
I am not sure if I am on the right way of thinking and designing. Since there
is no local assistance available, could you help to make things clearer?
Just a brief outline:
FOO is the C++ object, and Foo should be the S4 class. If the user creates an object, say bar, from
class Foo, the creation process automatically makes a new FOO object relating to bar in that a
unique name of the FOO instance is stored in a slot of bar. All the user then has to do is modify
bar by simple assignments. The getters and setters ("$", "[") are set up and
work. Each modification goes in hand with assigning new values to bar as well as updating the FOO
object through available setters from FOO.
So far, this way has brought me to about 100 lines, but now I read about
ReferenceClasses and was wondering, if there is a much easier way of achieving
my goals. Moreover, I was not sure any longer if my goals make sense or if a
more advanced programmer would do it totally different (and could share some
structural thinking on their approach).
The idea behind my way of doing was based upon several considerations. First, a
"classical" R object would not confuse users, as I assume users of my package
to be rather non-skilled (and not willing to change that). Second, I want to create a
properly programmed package for distribution on CRAN and publication, eventually. Third,
I want to save objects across sessions. So if a user restores a session, a simple
command, say, restore(), would do the trick to build all the related C++ objects again.
However, I admit that I still have not figured out how to automatically clean up the
workspace correctly before leaving a session, wanted or unwanted, that is, clean up
memory before leaving home. Fourth, pure arithmetic check is done in C++, however,
semantic check *should* be left to R, and the validity and class routines seem to be
perfect for this. Fifth, some work should be done in R, such as the passing of data
frames or samples from distributions.
I hope to get some structured ideas and hints how to start and/or proceed.
Thank you in advance,
Sören
Hello,
A C++ class that is exposed through an Rcpp module is already a
reference class, and so you can add methods, etc ...
Consider this example :
require(inline)
require(Rcpp)
fx <- cxxfunction( , '', includes = '
class FOO{
public:
FOO( double x_, double y_): x(x_), y(y_){}
double x ;
double y ;
void move( double dx, double dy){
x += dx ;
y += dy ;
}
} ;
RCPP_MODULE(mod){
class_("FOO" )
.constructor()
.field( "x", &FOO::x )
.field( "y", &FOO::y )
.method( "move", &FOO::move )
;
}
', plugin = "Rcpp" )
mod <- Module( "mod", getDynLib(fx),mustStart = TRUE )
# grab the exposed C++ class
FOO <- mod$FOO
# add R methods
FOO$methods(
bla = function() x+y,
reset = function() {
x <<- 0.0
y <<- 0.0
}
)
# create an instance
f <- new( FOO, 2.0, 3.0 )
# call an R method
f$reset()
# call a C++ method
f$move( 2.0, 2.0 )
# call an R method
f$bla()
Hope this helps.
Romain
--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
http://romain-francois.com
|- http://bit.ly/hdKhCy : Rcpp article in JSS
|- http://bit.ly/elZJRJ : Montpellier Comedie Club - Avril 2011
`- http://bit.ly/fhqbRC : Rcpp workshop in Chicago on April 28th
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bug or feature: using "ANY" as a generic field class (was: '[R] Is there a (virtual) class that all R objects inherit from?)
Thanks a lot for your reply and I'm sorry if I didn't make it quite
clear what I expected, but you got it right:
I'd simply like to see the same behavior for Reference Classes as for S4
classes when extending classes with "ANY" fields as featured in the
example below.
> setClass("A", representation(x="ANY"))
[1] "A"
> setClass("B", contains="A", representation(x="character"))
[1] "B"
> new("B", x = "abc")
An object of class "B"
Slot "x":
[1] "abc"
Thanks for addressing this!
Regards,
Janko
On 03.06.2011 19:13, John Chambers wrote:
Well, your mail is unclear as to what you expected, but there is one
bug shown by your example.
The behavior of S4 classes is sensible, at least as far as the example
shows:
> setClass("A", representation(x="ANY"))
[1] "A"
> setClass("B", contains="A", representation(x="character"))
[1] "B"
> new("B", x=1:3)
Error in validObject(.Object) :
invalid class "B" object: invalid object for slot "x" in class "B":
got class "integer", should be or extend class "character"
You couldn't expect the new() call to work, as the error message
clearly explains. A legitimate call does work:
> new("B", x = "abc")
An object of class "B"
Slot "x":
[1] "abc"
The reference classes should work the same way, but don't, as your
example shows.
A <- setRefClass(
+ Class="A",
+ fields=list(
+ .PRIMARYDATA="ANY"
+ ),
+ contains=c("VIRTUAL")
+ )
> B <- setRefClass(
+ Class="B",
+ fields=list(
+ .PRIMARYDATA="character"
+ ),
+ contains=c("A")
+ )
Error in `insertFields<-`(`*tmp*`, value = "character") :
The overriding class("character") of field ".PRIMARYDATA" is not a
subclass of the existing field definition ("ANY")
We'll fix that. And, yes, "ANY" is intended as a universal
superclass, but is usually not mentioned explicitly.
On 6/3/11 6:53 AM, Janko Thyson wrote:
Dear list,
I was wondering if you could help me out in clarifying something:
Is it possible to use class "ANY" in slots/fields of formal classes
if you
a) do not want to restrict valid classes of that field and
b) if you are making explicit use of class inheritance?
It seems to work in simple scenarios but produces errors when class
inheritance comes into play. So I was wondering if that's a feature or a
bug.
If using "ANY" is not the right way, I'd appreciate a pointer to how you
can to this.
See previous post with an example below.
Regards,
Janko
On 06/03/2011 01:53 AM, Janko Thyson wrote:
On 31.05.2011 18:17, Martin Morgan wrote:
On 05/30/2011 07:02 AM, Janko Thyson wrote:
Dear list,
I would like to set one specific Reference Class field to be of an
arbitrary class. Is there a class that all R objects inherit from? I
thought that "ANY" was something like this, but obviously that's not
true:
inherits(1:3, "ANY")
[1] FALSE
I can't speak to the implementation, but ANY functions as a base class
in terms of slot / field assignment and inheritance, e.g.,
setClass("A", representation(x="ANY"))
new("A", x=1:3)
Martin
Hi Martin,
sorry for the late response. The way you do it works. Yet, when you
declare dependencies more explicitly (contains=XY), then R
complains. Is
this a feature or a bug (with respect to the "less explicit" way
working
just fine)? See the example below:
# S4
setClass("A", representation(x="ANY"))
new("A", x=1:3)
setClass("A", representation(x="ANY"))
setClass("B", contains="A", representation(x="character"))
new("B", x=1:3)
# Reference Classes
setRefClass(
Class="A",
fields=list(
.PRIMARYDATA="ANY"
),
contains=c("VIRTUAL")
)
B<- setRefClass(
Class="B",
fields=list(
.PRIMARYDATA="character"
),
contains=c("A")
)
Bug, I'd say. Martin
Regards,
Janko
Regards,
Janko
[[alternative HTML version deleted]]
__
r-h...@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide
http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
__
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] C-Side: Applying a function (given as param) to data (given as param)
On Jun 5, 2011, at 12:22 PM, oliver wrote:
> On Sat, Jun 04, 2011 at 07:51:08AM -0400, Duncan Murdoch wrote:
>> On 11-06-03 4:19 PM, oliver wrote:
>>> On Fri, Jun 03, 2011 at 11:14:39AM -0500, Douglas Bates wrote:
On Fri, Jun 3, 2011 at 5:17 AM, oliver wrote:
> Hello,
>
> I'm implementing a package (C-extension),
> where one function gets data and a function
> [...]
>
> [...]
to be in The R Journal. They show an explicit example of apply in
compiled code (C++ using the Rcpp structures, in their case).
>>>
>>>
>>> As just mentioned: I already created successfully a C-extension for R.
>>>
>>> But I would like to know, how to call a function that I get via
>>> SEXP as parameter. How can I find out the function definition,
>>> for example the arity of the function and which arguments
>>> a function uses.
>>
>> You should almost certainly do this in R, not in C. If you are
>> doing it in C code you'll just be duplicating the implementation
>> from R, and your code will break if that implementation ever
>> changes.
> [...]
>
> The reason why I wanted to do this in C, not in R,
> is speed as well as consistency.
>
> I have about 700 MB data that I want to analyse
>
> And loops might be to slow in R.
> Some of the apply functions might help and I already implemented
> some stuff in R, but the result values that some of the apply functions give
> me,
> are changing under certain circumstances, for example list or matrix or
> vector.
> Also a lot of conversions and value-extracting is needed.
> It looked to me as if doing in C would be the better way.
>
> So I want to have the possibility to do that in C,
> then loops are no problem, and I can create a certain
> result value type, as well as some other features I have in mind.
> Also in R the automatic coercion to some types sometimes
> is not necessary, and working on the raw values might be
> better, it seems to me.
>
> Also I want to learn the C-interface, so that in later cases
> I know how to use it.
>
> For simple values I already know how to use it.
> But the problem is there, when functions are given as parameters.
> That is a very powerful feature. If that only is manageable easy in
> R, it might always be a performance bottleneck.
>
One thing you should realize is that when you pass a function it is a *R*
function (closure) so you are already leaving the C level the moment you need
to use it (=evaluate it). Note that loops are not slow in general in R, they
are slow compared to scalar computations but that's not the case here so I
don't expect much difference in speed, either.
That said, if you get something like function(x) passed via .Call as SEXP the
way to use it is simply:
SEXP useMe(SEXP myFun) {
SEXP xValue = ... /* value to pass ... */
SEXP env = ... /* where to eval ...* /
SEXP result = eval(lang2(myFun, xValue), env);
}
so a trivial sort of lapply for a sequence would be something like
SEXP lapply10(SEXP myFun) {
SEXP sIndex = PROTECT(allocVector(INTSXP, 1));
SEXP result = PROTECT(allocVector(VECSXP, 10));
int *index = INTEGER(sIndex);
for (int i = 0; i < 10; i++) {
index[0] = i + 1;
SET_VECTOR_ELT(result, i, eval(lang2(myFun, sIndex),
R_GlobalEnv));
}
UNPROTECT(2);
return result;
}
Cheers,
Simon
>
>>
>> In R you use formals(fn) to extract the function header.
>
> OK, thanks.
>
>
>>
>>>
>>> The problem is, that the C-standard (at least the first ANSI-C standard)
>>> does not guarantee portability for C-pointers.
>>> To be portable, for example the function pointer you use must
>>> definitely be of same type as the function you use.
>>>
>>> So I need to know how I can use the SEXP-function pointers.
>>
>> They are not function pointers, they are pointers to R objects.
> [...]
>
> Aha, good to know.
>
> Do I have to look at S3 and S4 methods and classses, if I wish to
> make it in C?
>
> Ciao,
> Oliver
>
> __
> 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] Possible bug in termplot function (stats package) ?
Hi all,
I noticed some very odd behaviour in the termplot function of the
stats package due to the following lines :
18.if (is.null(data))
19. data <- eval(model$call$data, envir)
This one will look in the global environment, and renders the two
lines after this
20. if (is.null(data))
21.data <- mf
completely obsolete. If nothing is found, an error is returned. If
anything is found, data won't be NULL, so line 20, when reached, will
always return FALSE. Can it be that lines 18 and 19 should be removed
from the function?
This gives especially problems when called from other plot functions
on models made with wrapper functions. One example :
Data <- data.frame(
x1=rnorm(100),
x2=rnorm(100,3,2),
y=rnorm(100)
)
form <- as.formula(y~x1+x2)
test <- lm(form, data=Data)
termplot(test)
wrapper <- function(ff,x){
tt <- lm(ff,data=x)
}
test2 <- wrapper(form,Data)
termplot(test2)
For the non-smooth terms, termplot is called. In the first example,
this works perfectly well. In the second example, it either returns "x
not found" (when there is no x variable in the global) or "x2 not
found" when there is an x variable.
If both lines mentioned earlier are erased from the function, it works
as expected in this example code. Using the model frame seems the
logic choice here, I have no clue why one would want to look in the
global environment for the data related to a model.
Cheers
Joris
--
Joris Meys
Statistical consultant
Ghent University
Faculty of Bioscience Engineering
Department of Applied mathematics, biometrics and process control
tel : +32 9 264 59 87
joris.m...@ugent.be
---
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Log file of building vignette in RCMD check
Hello, I am trying to run "RCMD check" on a package. It performs OK, with the exception of a single warning: * checking package vignettes in 'inst/doc' ... WARNING Package vignette(s) without corresponding PDF: AnnotationFuncsUserguide.Rnw As I understand the problem, the vignette is not built. However, I have no problems in doing so manually. How do I fix this problem? I cannot find any logs for building the vignette, however the output from building the pdf-file of the manual is found in the .Rcheck folder. On a similar note, as my vignette includes a biblio, I have to run "latex" twice to get the citations referenced properly with a number. Is this an issue? How can I work around it? (The package is submitted to BioC, so there might be other rules there?) Thank you in advanced. Yours sincerely, Stefan McKinnon Høj-Edwards Dept. of Genetics and Biotechnology PhD student Faculty of Agricultural Sciences stefan.hoj-edwa...@agrsci.dkAarhus University Tel.: +45 8999 1291 Blichers Allé 20, Postboks 50 Web: www.iysik.com DK-8830 Tjele Tel.: +45 8999 1900 Web: www.agrsci.au.dk __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] read.csv and FileEncoding in Windows version of R 2.13.0
Hello Duncan, thank you very much for your reply. The file is attached.
Again, the issue is that opening this UTF-8 encoded file under R 2.13.0 yields
an error, but opening it under R 2.12.2 works without any issues.
The command I used to open the file is:
read.csv("test.csv",fileEncoding="UTF-8",header=FALSE)
(As you'll see, the file does have a byte order mark.)
Regards,
Alex
-Original Message-
From: Duncan Murdoch [mailto:murdoch.dun...@gmail.com]
Sent: Wednesday, June 01, 2011 7:35 PM
To: Alexander Peterhansl
Cc: R-devel@r-project.org
Subject: Re: [Rd] read.csv and FileEncoding in Windows version of R 2.13.0
On 01/06/2011 6:00 PM, Alexander Peterhansl wrote:
>
> Dear R-devel List:
>
> read.csv() seems to have changed in R version 2.13.0 as compared to version
> 2.12.2 when reading in simple CSV files.
>
> Suppose I read in a 2-column CSV file ("test.csv"), say 1, a 2, b
>
> If file is encoded as UTF-8 (on Windows 7), then under R 2.13.0
That file could be pure ASCII, or could include a byte order mark. I tried
both, and I didn't get the error your saw. So I think I need to see the file
to diagnose this.
Could you put it in a .zip file and email it to me?
Duncan Murdoch
> read.csv("test.csv",fileEncoding="UTF-8",header=FALSE) yields the following
> output
>V1
> 1 ?
> Warning messages:
> 1: In read.table(file = file, header = header, sep = sep, quote = quote, :
>invalid input found on input connection 'test.csv'
> 2: In read.table(file = file, header = header, sep = sep, quote = quote, :
>incomplete final line found by readTableHeader on 'test.csv'
>
> Under R 2.12.2 it runs problem-free and yields the expected:
>V1 V2
> 1 1 a
> 2 2 b
>
> Please help.
>
> Regards,
> Alex
>
> [[alternative HTML version deleted]]
>
> __
> 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] Log file of building vignette in RCMD check
On 06.06.2011 15:30, Stefan McKinnon Høj-Edwards wrote: Hello, I am trying to run "RCMD check" on a package. It performs OK, with the exception of a single warning: * checking package vignettes in 'inst/doc' ... WARNING Package vignette(s) without corresponding PDF: AnnotationFuncsUserguide.Rnw R CMD build should build the vignettes. If it did not succeed, see its output for details. Uwe Ligges As I understand the problem, the vignette is not built. However, I have no problems in doing so manually. How do I fix this problem? I cannot find any logs for building the vignette, however the output from building the pdf-file of the manual is found in the .Rcheck folder. On a similar note, as my vignette includes a biblio, I have to run "latex" twice to get the citations referenced properly with a number. Is this an issue? How can I work around it? (The package is submitted to BioC, so there might be other rules there?) Thank you in advanced. Yours sincerely, Stefan McKinnon Høj-Edwards Dept. of Genetics and Biotechnology PhD student Faculty of Agricultural Sciences stefan.hoj-edwa...@agrsci.dkAarhus University Tel.: +45 8999 1291 Blichers Allé 20, Postboks 50 Web: www.iysik.com DK-8830 Tjele Tel.: +45 8999 1900 Web: www.agrsci.au.dk __ 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] Bug or feature: using "ANY" as a generic field class (was: '[R] Is there a (virtual) class that all R objects inherit from?)
Should now behave as expected in r-devel and 2.13 patched, as of SVN
56045, June 4. (noted in the NEWS file.)
On 6/6/11 6:27 AM, Janko Thyson wrote:
Thanks a lot for your reply and I'm sorry if I didn't make it quite
clear what I expected, but you got it right:
I'd simply like to see the same behavior for Reference Classes as for S4
classes when extending classes with "ANY" fields as featured in the
example below.
> setClass("A", representation(x="ANY"))
[1] "A"
> setClass("B", contains="A", representation(x="character"))
[1] "B"
> new("B", x = "abc")
An object of class "B"
Slot "x":
[1] "abc"
Thanks for addressing this!
Regards,
Janko
On 03.06.2011 19:13, John Chambers wrote:
Well, your mail is unclear as to what you expected, but there is one
bug shown by your example.
The behavior of S4 classes is sensible, at least as far as the example
shows:
> setClass("A", representation(x="ANY"))
[1] "A"
> setClass("B", contains="A", representation(x="character"))
[1] "B"
> new("B", x=1:3)
Error in validObject(.Object) :
invalid class "B" object: invalid object for slot "x" in class "B":
got class "integer", should be or extend class "character"
You couldn't expect the new() call to work, as the error message
clearly explains. A legitimate call does work:
> new("B", x = "abc")
An object of class "B"
Slot "x":
[1] "abc"
The reference classes should work the same way, but don't, as your
example shows.
A <- setRefClass(
+ Class="A",
+ fields=list(
+ .PRIMARYDATA="ANY"
+ ),
+ contains=c("VIRTUAL")
+ )
> B <- setRefClass(
+ Class="B",
+ fields=list(
+ .PRIMARYDATA="character"
+ ),
+ contains=c("A")
+ )
Error in `insertFields<-`(`*tmp*`, value = "character") :
The overriding class("character") of field ".PRIMARYDATA" is not a
subclass of the existing field definition ("ANY")
We'll fix that. And, yes, "ANY" is intended as a universal superclass,
but is usually not mentioned explicitly.
On 6/3/11 6:53 AM, Janko Thyson wrote:
Dear list,
I was wondering if you could help me out in clarifying something:
Is it possible to use class "ANY" in slots/fields of formal classes
if you
a) do not want to restrict valid classes of that field and
b) if you are making explicit use of class inheritance?
It seems to work in simple scenarios but produces errors when class
inheritance comes into play. So I was wondering if that's a feature or a
bug.
If using "ANY" is not the right way, I'd appreciate a pointer to how you
can to this.
See previous post with an example below.
Regards,
Janko
On 06/03/2011 01:53 AM, Janko Thyson wrote:
On 31.05.2011 18:17, Martin Morgan wrote:
On 05/30/2011 07:02 AM, Janko Thyson wrote:
Dear list,
I would like to set one specific Reference Class field to be of an
arbitrary class. Is there a class that all R objects inherit from? I
thought that "ANY" was something like this, but obviously that's not
true:
inherits(1:3, "ANY")
[1] FALSE
I can't speak to the implementation, but ANY functions as a base class
in terms of slot / field assignment and inheritance, e.g.,
setClass("A", representation(x="ANY"))
new("A", x=1:3)
Martin
Hi Martin,
sorry for the late response. The way you do it works. Yet, when you
declare dependencies more explicitly (contains=XY), then R
complains. Is
this a feature or a bug (with respect to the "less explicit" way
working
just fine)? See the example below:
# S4
setClass("A", representation(x="ANY"))
new("A", x=1:3)
setClass("A", representation(x="ANY"))
setClass("B", contains="A", representation(x="character"))
new("B", x=1:3)
# Reference Classes
setRefClass(
Class="A",
fields=list(
.PRIMARYDATA="ANY"
),
contains=c("VIRTUAL")
)
B<- setRefClass(
Class="B",
fields=list(
.PRIMARYDATA="character"
),
contains=c("A")
)
Bug, I'd say. Martin
Regards,
Janko
Regards,
Janko
[[alternative HTML version deleted]]
__
r-h...@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide
http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
*Janko Thyson*
janko.thy...@ku-eichstaett.de
Catholic University of Eichstätt-Ingolstadt
Ingolstadt School of Management
Statistics and Quantitative Methods
Auf der Schanz 49
D-85049 Ingolstadt
www.wfi.edu/lsqm
Fon: +49 841 937-1923
Fax: +49 841 937-1965
This e-mail and any attachment is for authorized use by the intended
recipient(s) only. It may contain proprietary material, confidential
information and/or be subject to legal privilege. It should not be
copied, disclosed to, retained or used by any other party.
If you are not an intended recipient then please promptly delete this
e-mail and a
Re: [Rd] Possible bug in termplot function (stats package) ?
On Jun 6, 2011, at 17:15 , Joris Meys wrote:
> Hi all,
>
> I noticed some very odd behaviour in the termplot function of the
> stats package due to the following lines :
>
> 18.if (is.null(data))
> 19. data <- eval(model$call$data, envir)
>
> This one will look in the global environment, and renders the two
> lines after this
>
> 20. if (is.null(data))
> 21.data <- mf
>
> completely obsolete. If nothing is found, an error is returned. If
> anything is found, data won't be NULL, so line 20, when reached, will
> always return FALSE. Can it be that lines 18 and 19 should be removed
> from the function?
I think this is a false assumption. What keeps model$call$data from being NULL?
No comments on the remainder, except that it wouldn't be the first time a
wrapper function got into trouble with environments and modelling functions...
>
> This gives especially problems when called from other plot functions
> on models made with wrapper functions. One example :
>
> Data <- data.frame(
> x1=rnorm(100),
> x2=rnorm(100,3,2),
> y=rnorm(100)
> )
> form <- as.formula(y~x1+x2)
> test <- lm(form, data=Data)
> termplot(test)
>
> wrapper <- function(ff,x){
> tt <- lm(ff,data=x)
> }
> test2 <- wrapper(form,Data)
> termplot(test2)
>
> For the non-smooth terms, termplot is called. In the first example,
> this works perfectly well. In the second example, it either returns "x
> not found" (when there is no x variable in the global) or "x2 not
> found" when there is an x variable.
>
> If both lines mentioned earlier are erased from the function, it works
> as expected in this example code. Using the model frame seems the
> logic choice here, I have no clue why one would want to look in the
> global environment for the data related to a model.
>
> Cheers
> Joris
>
> --
> Joris Meys
> Statistical consultant
>
> Ghent University
> Faculty of Bioscience Engineering
> Department of Applied mathematics, biometrics and process control
>
> tel : +32 9 264 59 87
> joris.m...@ugent.be
> ---
> Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Peter Dalgaard
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Fwd: Error in svg() : cairo-based devices are not supported on this build
Check what configure is saying when you build R and config.log. You may be
> simply missing something like pango-dev - Cairo doesn't use pango while R
> does - but it is usually optional (it works on my Mac without pango) so
> there may be more to it - config.log will tell you.
>
I managed to compile it successfully with pango-cairo support by editing the
configure script and adding the pangoxft module to the pkg-config list:
%diff -c configure.bak configure
*** configure.bak 2011-05-31 16:16:55.0 +0200
--- configure 2011-05-31 16:17:21.0 +0200
***
*** 31313,31319
$as_echo "$r_cv_has_pangocairo" >&6; }
if test "x${r_cv_has_pangocairo}" = "xyes"; then
modlist="pangocairo"
! for module in cairo-xlib cairo-png; do
if "${PKGCONF}" --exists ${module}; then
modlist="${modlist} ${module}"
fi
--- 31313,31319
$as_echo "$r_cv_has_pangocairo" >&6; }
if test "x${r_cv_has_pangocairo}" = "xyes"; then
modlist="pangocairo"
! for module in cairo-xlib cairo-png pangoxft; do
if "${PKGCONF}" --exists ${module}; then
modlist="${modlist} ${module}"
fi
I do not know if it is an error in the configure script or just a
peculiarity of my installation. All these libs (pango, cairo, gtk, glib)
have been installed manually from tarballs.
Best,
Karl
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bug or feature: using "ANY" as a generic field class
Wow, that was fast! Thanks a lot!
Regards,
Janko
On 06.06.2011 18:29, John Chambers wrote:
> Should now behave as expected in r-devel and 2.13 patched, as of SVN
> 56045, June 4. (noted in the NEWS file.)
>
>
> On 6/6/11 6:27 AM, Janko Thyson wrote:
>> Thanks a lot for your reply and I'm sorry if I didn't make it quite
>> clear what I expected, but you got it right:
>>
>> I'd simply like to see the same behavior for Reference Classes as for S4
>> classes when extending classes with "ANY" fields as featured in the
>> example below.
>>
>> > setClass("A", representation(x="ANY"))
>> [1] "A"
>> > setClass("B", contains="A", representation(x="character"))
>> [1] "B"
>> > new("B", x = "abc")
>> An object of class "B"
>> Slot "x":
>> [1] "abc"
>>
>> Thanks for addressing this!
>>
>> Regards,
>> Janko
>>
>> On 03.06.2011 19:13, John Chambers wrote:
>>> Well, your mail is unclear as to what you expected, but there is one
>>> bug shown by your example.
>>>
>>> The behavior of S4 classes is sensible, at least as far as the example
>>> shows:
>>>
>>>
>>> > setClass("A", representation(x="ANY"))
>>> [1] "A"
>>> > setClass("B", contains="A", representation(x="character"))
>>> [1] "B"
>>> > new("B", x=1:3)
>>> Error in validObject(.Object) :
>>> invalid class "B" object: invalid object for slot "x" in class "B":
>>> got class "integer", should be or extend class "character"
>>>
>>> You couldn't expect the new() call to work, as the error message
>>> clearly explains. A legitimate call does work:
>>>
>>> > new("B", x = "abc")
>>> An object of class "B"
>>> Slot "x":
>>> [1] "abc"
>>>
>>> The reference classes should work the same way, but don't, as your
>>> example shows.
>>>
>>> A <- setRefClass(
>>> + Class="A",
>>> + fields=list(
>>> + .PRIMARYDATA="ANY"
>>> + ),
>>> + contains=c("VIRTUAL")
>>> + )
>>> > B <- setRefClass(
>>> + Class="B",
>>> + fields=list(
>>> + .PRIMARYDATA="character"
>>> + ),
>>> + contains=c("A")
>>> + )
>>> Error in `insertFields<-`(`*tmp*`, value = "character") :
>>> The overriding class("character") of field ".PRIMARYDATA" is not a
>>> subclass of the existing field definition ("ANY")
>>>
>>> We'll fix that. And, yes, "ANY" is intended as a universal superclass,
>>> but is usually not mentioned explicitly.
>>>
>>>
>>> On 6/3/11 6:53 AM, Janko Thyson wrote:
Dear list,
I was wondering if you could help me out in clarifying something:
Is it possible to use class "ANY" in slots/fields of formal classes
if you
a) do not want to restrict valid classes of that field and
b) if you are making explicit use of class inheritance?
It seems to work in simple scenarios but produces errors when class
inheritance comes into play. So I was wondering if that's a feature
or a
bug.
If using "ANY" is not the right way, I'd appreciate a pointer to
how you
can to this.
See previous post with an example below.
Regards,
Janko
On 06/03/2011 01:53 AM, Janko Thyson wrote:
> On 31.05.2011 18:17, Martin Morgan wrote:
>> On 05/30/2011 07:02 AM, Janko Thyson wrote:
>>> Dear list,
>>>
>>> I would like to set one specific Reference Class field to be of an
>>> arbitrary class. Is there a class that all R objects inherit
>>> from? I
>>> thought that "ANY" was something like this, but obviously that's
>>> not
>>> true:
>>>
inherits(1:3, "ANY")
>>> [1] FALSE
>>
>> I can't speak to the implementation, but ANY functions as a base
>> class
>> in terms of slot / field assignment and inheritance, e.g.,
>>
>> setClass("A", representation(x="ANY"))
>> new("A", x=1:3)
>>
>> Martin
>
> Hi Martin,
>
> sorry for the late response. The way you do it works. Yet, when you
> declare dependencies more explicitly (contains=XY), then R
> complains. Is
> this a feature or a bug (with respect to the "less explicit" way
> working
> just fine)? See the example below:
>
> # S4
> setClass("A", representation(x="ANY"))
> new("A", x=1:3)
>
> setClass("A", representation(x="ANY"))
> setClass("B", contains="A", representation(x="character"))
> new("B", x=1:3)
>
> # Reference Classes
> setRefClass(
> Class="A",
> fields=list(
> .PRIMARYDATA="ANY"
> ),
> contains=c("VIRTUAL")
> )
> B<- setRefClass(
> Class="B",
> fields=list(
> .PRIMARYDATA="character"
> ),
> contains=c("A")
> )
Bug, I'd say. Martin
>
> Regards,
> Janko
>>>
>>> Regards,
>>> Janko
>>>
>>> [[alternative HTML version deleted]]
>>>
>>> __
>>> r-h...@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-help
>>> PLEASE do read the posting guide
>>> http://www.R-project.org/posting-guide.html
>>> and provide commented, minima
[Rd] Reference Classes: shortcut like 'isS4' for Ref Classes?
Dear list,
is there a shortcut-function to check whether a class is a Reference
Class or not? There's something like this for S4 classes
('isS4(object)'), but I couldn't find anything regarding Ref Classes.
Currently, I'm doing it this way, which is a bit clumsy:
A <- setRefClass("A", fields=list(X="numeric"))
a <- A$new()
isRefClass <- function(object, ...){
return(getClass(class(object))@class == "refClassRepresentation")
#getRefClass(class(object))@class == "refObjectGenerator"
}
isRefClass(a)
[1] TRUE
Regards,
Janko
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Log file of building vignette in RCMD check
On Mon, 6 Jun 2011, Uwe Ligges wrote: On 06.06.2011 15:30, Stefan McKinnon Høj-Edwards wrote: Hello, I am trying to run "RCMD check" on a package. It performs OK, with the exception of a single warning: * checking package vignettes in 'inst/doc' ... WARNING Package vignette(s) without corresponding PDF: AnnotationFuncsUserguide.Rnw R CMD build should build the vignettes. If it did not succeed, see its output for details. You can also use tools::buildVignettes to do it manually. But R CMD check is reporting that you failed to do it at all: it is not the job of R CMD check and the PDF of the vignette should be in the tarball/directory you supply to be checked. Uwe Ligges As I understand the problem, the vignette is not built. However, I have no problems in doing so manually. How do I fix this problem? I cannot find any logs for building the vignette, however the output from building the pdf-file of the manual is found in the .Rcheck folder. On a similar note, as my vignette includes a biblio, I have to run "latex" twice to get the citations referenced properly with a number. Is this an issue? How can I work around it? (The package is submitted to BioC, so there might be other rules there?) It indicates that you failed to use the tools we provided, R CMD build, tools::buildVignettes() and tools::texi2dvi(). Thank you in advanced. Yours sincerely, Stefan McKinnon Høj-Edwards Dept. of Genetics and Biotechnology PhD student Faculty of Agricultural Sciences stefan.hoj-edwa...@agrsci.dkAarhus University Tel.: +45 8999 1291 Blichers Allé 20, Postboks 50 Web: www.iysik.com DK-8830 Tjele Tel.: +45 8999 1900 Web: www.agrsci.au.dk -- Brian D. Ripley, rip...@stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595__ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Possible bug in termplot function (stats package) ?
On Mon, Jun 6, 2011 at 6:29 PM, peter dalgaard wrote:
>
> On Jun 6, 2011, at 17:15 , Joris Meys wrote:
>
**snip**
>> If nothing is found, an error is returned. If
>> anything is found, data won't be NULL, so line 20, when reached, will
>> always return FALSE. Can it be that lines 18 and 19 should be removed
>> from the function?
>
>
> I think this is a false assumption. What keeps model$call$data from being
> NULL?
>
Apart from a dataframe that is explicitly assigned NULL, I can't
imagine a case where model$call$data would be NULL. If it's not found,
the statement returns an error. If it is found and it is NULL, your
model call will have thrown an error earlier, so you won't even have
an object to plot. If you can give me one example where that code
actually makes sense, I'll be very happy. But right now, it doesn't
make any sense at all to me.
> No comments on the remainder, except that it wouldn't be the first time a
> wrapper function got into trouble with environments and modelling functions...
>
My wrapper function returns a completely sound lm-object. Why wouldn't
I expect a function built to work on lm-objects to work on an
lm-object? At least the help files should note that the dataframe will
be sought in the calling environment, or it won't work on your fitted
objects.
Right now I have to do something like :
termplot.wrapper <- function(x,...){
x$call$data <- NULL
termplot(x)
}
which seems at least a tiny bit awkward...
Cheers
Joris
--
Joris Meys
Statistical consultant
Ghent University
Faculty of Bioscience Engineering
Department of Applied mathematics, biometrics and process control
tel : +32 9 264 59 87
joris.m...@ugent.be
---
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Possible bug in termplot function (stats package) ?
On Jun 6, 2011, at 20:38 , Joris Meys wrote: > On Mon, Jun 6, 2011 at 6:29 PM, peter dalgaard wrote: >> >> On Jun 6, 2011, at 17:15 , Joris Meys wrote: >> > **snip** >>> If nothing is found, an error is returned. If >>> anything is found, data won't be NULL, so line 20, when reached, will >>> always return FALSE. Can it be that lines 18 and 19 should be removed >>> from the function? >> >> >> I think this is a false assumption. What keeps model$call$data from being >> NULL? >> > Apart from a dataframe that is explicitly assigned NULL, I can't > imagine a case where model$call$data would be NULL. If it's not found, > the statement returns an error. If it is found and it is NULL, your > model call will have thrown an error earlier, so you won't even have > an object to plot. If you can give me one example where that code > actually makes sense, I'll be very happy. But right now, it doesn't > make any sense at all to me. I'd say that the burden of proof is really on your side, but how hard can it be: > x <- 1:10 > y <- rnorm(10) > m <- lm(y~x) > m$call lm(formula = y ~ x) > m$call$data NULL -- Peter Dalgaard Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Possible bug in termplot function (stats package) ?
On Mon, Jun 6, 2011 at 9:15 PM, peter dalgaard wrote: > > I'd say that the burden of proof is really on your side, but how hard can it > be: > >> x <- 1:10 >> y <- rnorm(10) >> m <- lm(y~x) >> m$call > lm(formula = y ~ x) >> m$call$data > NULL > I see... indeed, thx for the answer and sorry for my stupidity. Should have thought about that case. Still, I wonder why it is necessary to go look for the data in a calling environment if it should be contained in the model frame of the fitted object. Or am I again wrong in assuming that's always the case? Cheers Joris -- Joris Meys Statistical consultant Ghent University Faculty of Bioscience Engineering Department of Applied mathematics, biometrics and process control tel : +32 9 264 59 87 joris.m...@ugent.be --- Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Possible bug in termplot function (stats package) ?
On Tue, Jun 7, 2011 at 7:30 AM, Joris Meys wrote: > On Mon, Jun 6, 2011 at 9:15 PM, peter dalgaard wrote: >> >> I'd say that the burden of proof is really on your side, but how hard can it >> be: >> >>> x <- 1:10 >>> y <- rnorm(10) >>> m <- lm(y~x) >>> m$call >> lm(formula = y ~ x) >>> m$call$data >> NULL >> > I see... indeed, thx for the answer and sorry for my stupidity. Should > have thought about that case. Still, I wonder why it is necessary to > go look for the data in a calling environment if it should be > contained in the model frame of the fitted object. Or am I again wrong > in assuming that's always the case? You are again wrong. Life would be much simpler if the data were always available like that, but there are at least two problems. 1) There need not be a model frame in the fitted object. (it's optional) 2) More importantly, if you have y~sin(x), the model frame will contain sin(x), not x. For what termplot() does, it has to be able to reconstruct 'x', which isn't possible without the original data. It's quite possible that termplot() could be rewritten to be simpler and more general, but I don't think minor editing will do it. -thomas -- Thomas Lumley Professor of Biostatistics University of Auckland __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Overloading S4 methods
This is a bug, medium-subtle, but also raises an interesting software
design point.
The Bug:
Nothing specific about "ANY" and "missing", but the issue is whether the
method was inherited (the "ANY" case) or defined directly (the "missing"
case).
Generic functions keep a cached table of dispatched methods, to save
determining inherited methods repeatedly for calls with the same
signature. When pkg B is loaded, the inherited methods are reset, but
apparently the directly defined ones were not (but should have been if
pkg B overrides the method).
It's interesting that this bug seems not to have been reported before,
which leads to:
The Software Design Point:
When a package (B) extends the class/method software in another package
(A), typically B adds new classes and perhaps new generic functions with
methods for previous classes in A as well as classes in B. It might
also extend the behavior for classes in A to other generic functions.
What is less usual is to directly override an existing method for a
class that belongs to A. Notice that there can be side-effects, such as
behavior of examples or tests in package A depending on whether B has
been loaded or not. And objects created entirely from A could have
their computations change after B was loaded.
Nothing at all illegal here, and we'll make it work. But a more
predictable implementation for most applications would, say, define a
new class in B that extended the class in A. In your example (very
helpful, by the way) one might have a class "mynumB", perhaps with the
same slots as "mynum" but with modified behavior.
If you want to keep the current implementation, though, a workaround
until the bug is fixed would be something like:
setMethod("plot", c("mynum", "missing"), getMethod("plot", c("mynum",
"missing")))
executed after B is attached (I think it could be in the .onLoad
function for B, but have not tested that).
John
On 6/6/11 4:11 AM, Iago Mosqueira wrote:
On Wed, Jun 1, 2011 at 6:04 PM, Martin Morgan wrote:
On 06/01/2011 04:39 AM, Iago Mosqueira wrote:
Dear all,
I am experiencing some problems with S4 method overloading. I have
defined a generic for graphics:plot, using
setGeneric("plot", useAsDefault = plot)
and with
importFrom('graphics', 'plot') and
exportMethods('plot') in the NAMESPACE file of pkg A.
I'd guess you were creating two generics (explicitly in pkgA, implicitly in
pkgB). Maybe
export(plot)
in NAMESPACE of pkg A,
importFrom('pkgA', plot)
exportMethods(plot)
in pkg B. Feel free to post to the list if that's helpful.
Martin
I then proceed to define a method for signature c('myS4class',
'missing'). This works as expected: selectMethod('plot',
c('myS4class', 'missing')) returns the newly defined method, and the
method gets called when invoked.
Another pkg, B, wishes to overload this and redefines the method for
the same signature. A method is defined for c('myS4class', 'missing'),
and exported on the NAMESPACE. The new method is shown by
selectMethod() after pkg B has been loaded, but a call to
plot(anobjectofmyS4class)
comes up with the result of running the first method, from pkg A. I
have tried importing 'plot' in B's NAMESPACE from both graphics or A,
but the end result is the same.
Package B does the same thing for a method created by pkg A, myMethod,
and that works fine.
Any pointers or where this might be going wrong? How is it that a
different method than the one shown by selectMethod() is being run?
Something to do with the 'missing' part of the signature?
Many thanks,
Iago Mosqueira
Dear all,
I have tried Martin's suggestion, but the problem persists. It seems
to be related to having 'missing' in the signature, as doing the same
kind of overloading for c('myclass', 'ANY') work as expected.
I am attaching 2 simple packages where I attempt this repeated
overloading of plot for the same class. Script below, also found in
Bpkg/tests.test.R, shows what I have encountered so far:
plot('myclass', 'ANY') can be re-overloaded, but plot('myclass',
'missing') cannot in the same way. If I run
trace("plot", browser, exit=browser, signature = c("mynum", "missing"))
the new method is actually called.
Any hint on what I am doing wrong or where to look for an explanation
will be much appreciated.
Best regards,
Iago Mosqueira
__
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] Reference Classes: shortcut like 'isS4' for Ref Classes?
As it says on the help page ?ReferenceClasses:
All reference classes inherit from the class "envRefClass"
So,
is(x, "envRefClass")
And, less well documented but less typing:
is(x, "refClass")
also works.
On 6/6/11 9:48 AM, Janko Thyson wrote:
Dear list,
is there a shortcut-function to check whether a class is a Reference
Class or not? There's something like this for S4 classes
('isS4(object)'), but I couldn't find anything regarding Ref Classes.
Currently, I'm doing it this way, which is a bit clumsy:
A <- setRefClass("A", fields=list(X="numeric"))
a <- A$new()
isRefClass <- function(object, ...){
return(getClass(class(object))@class == "refClassRepresentation")
# getRefClass(class(object))@class == "refObjectGenerator"
}
isRefClass(a)
[1] TRUE
Regards,
Janko
__
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
