Re: [Rd] Overloading S4 methods
On Mon, Jun 6, 2011 at 11:28 PM, John Chambers wrote:
> 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
Many thanks for the very complete explanation. We are using this
mechanism to provide ggplot2-based plot for some classes, to
substitute the initial lattice-based ones, so the effects are limited
to visual output and not results of computation, but it is good you
reminded me of the possible side effects of this strategy. Is maybe a
warning during R CMD check appropriate here?
Adding the call to setMethod(..., getMethod()) did not work if placed
inside .onLoad, and in fact had the effect of getMethod() now
returning the Apkg method after Bpkg was loaded.
Running the line after Bpkg has loaded did sort it out. What would
then be the best way of adding this command to the pkg loading
process? I have also tried adding it to a zzz.R file on iuts own but
that did not work, I still need to re-run it after loading has
finished.
Many thanks,
Iago
>
>
> 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
Re: [Rd] Interfacing a C++ class
On 06.06.2011, at 13:42, Romain Francois wrote:
> Le 04/06/11 16:31, soeren.vo...@uzh.ch a écrit :
>
>> 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.
>
> 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()
Thanks Simon and Romain for your great help! That C++ classes exposed via
Rcpp-modules are already reference classes helps a lot and saves time for
unnecessary mirroring. According to Romain saving class objects across sessions
remains to be implemented in Rcpp. I have not browsed the rJava package
extensively, but I found serialize() (base) and this function seems to provide
a workaround. Yet, I do not know how to use it in practice with my package.
Some thoughts: consider the small FOO example below. Then, on accidental crash
or quit(save="yes"), or whatever users may do, R "should" know that it has to
serialise all existing FOO objects. Note, that in my package these objects are
"sort of lists" that can become quite large (say, a vector of 15,000 numeric
values plus a character string). After restoring a previously saved image, R
"should know" to load my package, and that in turn should deserialise every FOO
object present in the image. Sounds like a not too complicated task, something
like .dofirst()/.dolast() -- but that again exceeds my R and C++ programming
skills, and I hope that you experts may share an idea. Thanks, Sören
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Cases of TAB-completion that hang Rterm
FYI,
via a bug report of one of my packages, I discovered that the
following cases will hang Rterm when using TAB completion:
CASE #1:
Adding an empty default function for tail() causes Rterm on Windows to
hang if one press TAB at the prompt:
% Rterm -vanilla
> tail.default <- function(...) {}
> [PRESS TAB]
Error in specialOpLocs(text) :
(list) object cannot be coerced to type 'double'
After this Rterm becomes completely unresponsive. The same error
message will show up with Rgui, but R remains responsive.
CASE #2:
While troubleshooting the above, I discovered that if one does:
> debug(utils:::.guessTokenFromLine)
> [PRESS TAB]
or
> debug(utils:::.win32consoleCompletion)
> [PRESS TAB]
then Rterm hangs too (not Rgui).
This happens with R v2.13.0 patched (2011-05-30 r56020) and R v2.14.0
devel (2011-05-30 r56020) on Windows.
/Henrik
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Does anybody successfully built latest R on AIX 5.3?
I am trying to install http://www.oss4aix.org/download/RPMS/gcc/gcc-4.2.4-2.aix5.3.ppc.rpm but it dependents on package info, which I can't find a version for AIX 5.3, can anyone who success fully built R on AIX 5.3 share which version of gcc and the related packages to use, and where to download them,thanks, following are the error messages: # rpm -i ./libgcc-4.2.4-2.aix5.3.ppc.rpm package libgcc-4.2.4-2 is already installed # rpm -i ./gcc-4.2.4-2.aix5.3.ppc.rpm error: failed dependencies: info is needed by gcc-4.2.4-2 # rpm -i ./info-4.13a-2.aix5.1.ppc.rpm error: ./info-4.13a-2.aix5.1.ppc.rpm does not appear to be a RPM package On Sat, Jun 4, 2011 at 1:16 PM, Xiaobo Gu wrote: > > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Packages for R-CRAN (organizing aspects)
Hello, I have some ideas for packages that I want to provide on R-CRAN. One package alreads is working, but I have some warnings in when compiling. Also I don't know if the libraries in use are only working on Unix/Linux. So I have some general questions: - If I'm not sure if the code would also work on windows (needing some ceratain libraries or tools), would it be better to mark it as Unix-like only? Would other people, who are interested in using the package on Windows, then look for the other issues? (I'm just interested in providing the functionality, and I don't use Windows, so compatibility would not be my main goal, if it's using certain libraries; but if the code is not relying on certain libs or tools I of course write code ANSI-conform, so that it *should* compile on windows too.) I mean: I just want to have the work for Unix/Linux, but in general like the platform-independent approach. I just have no interest, looking at the windows side too much. Are there people from R-CRAN team, who help at that point to make things available on many platforms? - I have in mind packages for reading a lot of different files / fileformat. How to name them? it would be consequent to name them read. but I'm not sure if this naming style is reserved for OO-methods only, and that topic I will learn later in detail, so that at the moment I just would provide the raw functionality. Maybe the name of the reading function should then better be named read or read ? - There are a lot of different fileformats that I want to read in. Would it be better to make for each format one different package, or rather put them all together as a package "Readmisc"? For example the following formats I have in mind: - jpeg (libjpeg62) => already working, I want to clean up the code and documentation soon and then provide on R-CRAN - bvh (maybe (f)lex or yacc or pcre) => want to start this soon - apachelogfile /maybe using pcre) => starting date not planned - some other formats also - Other package ideas: rolling application (which uses R's built in types, not like zoo() using special types) Can you give me some general advice on how to organize this best, so that it also fits into the R / R-CRAN philosophy?! Ciao, Oliver __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] "warning: assignment discards qualifiers from pointer target type"
Hello,
following an advice here from the list I looked into sources of other
packages (xts) and found the TYPEOF() macro/function, which really is
helpful.
I iused the follwong code snippet:
switch( TYPEOF( filename_sexp ) )
{
case STRSXP: filename = CHAR( STRING_ELT(filename_sexp, 0) );
break;
default: error("filename argument must be a string");
break;
}
Here, filename is of type char*
and one function opens a file with that name.
So it is purely intended to just grab out the char* from the
String-Expression.
Am I doing something wrong here, or is it ok, but I have somehow
to say the extracting macros/functions, that it is really intended
to throw away information and that a warning is not necessary?
Ciao,
Oliver
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Overloading S4 methods
On Mon, 6 Jun 2011, John Chambers wrote:
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.
Dylan is simliar in using a generic funciton model. One of the Dylan
books -- I forget which one -- strongly recomends that a library only
define a method if either it also defines the generic or if it defines
one of the classes the method is specialized on. THis isn't an enforced
requirement but a strong recommendation.
Best,
luke
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
Re: [Rd] Packages for R-CRAN (organizing aspects)
On Tue, Jun 7, 2011 at 9:03 AM, oliver wrote:
> Hello,
>
> I have some ideas for packages that I want to provide on R-CRAN.
>
> One package alreads is working, but I have some warnings in
> when compiling. Also I don't know if the libraries in use are only
> working on Unix/Linux.
>
> So I have some general questions:
>
> - If I'm not sure if the code would also work on windows
> (needing some ceratain libraries or tools),
> would it be better to mark it as Unix-like only?
>
> Would other people, who are interested in using the package
> on Windows, then look for the other issues?
>
> (I'm just interested in providing the functionality, and I don't use
> Windows,
> so compatibility would not be my main goal, if it's using certain
> libraries;
> but if the code is not relying on certain libs or tools I of course write
> code ANSI-conform, so that it *should* compile on windows too.)
>
> I mean: I just want to have the work for Unix/Linux, but in general like
> the
> platform-independent approach. I just have no interest, looking at the
> windows
> side too much. Are there people from R-CRAN team, who help at that point
> to make
> things available on many platforms?
>
>
> - I have in mind packages for reading a lot of different files / fileformat.
> How to name them?
> it would be consequent to name them
> read.
> but I'm not sure if this naming style is reserved for OO-methods only,
> and that topic I will learn later in detail, so that at the moment
> I just would provide the raw functionality.
>
> Maybe the name of the reading function should then better be named
> read or read ?
>
> - There are a lot of different fileformats that I want to read in.
>
> Would it be better to make for each format one different package,
> or rather put them all together as a package "Readmisc"?
>
> For example the following formats I have in mind:
>
> - jpeg (libjpeg62) => already working, I want to
> clean up the code and
> documentation
> soon and then provide on R-CRAN
>
Note existence of read.jpeg in the rimage package, read.gif in the
caTools package and readPNG in the png package.
> - bvh (maybe (f)lex or yacc or pcre) => want to start this soon
>
> - apachelogfile /maybe using pcre) => starting date not planned
>
> - some other formats also
>
>
> - Other package ideas: rolling application (which uses R's built in types,
> not like zoo() using special types)
rollapply and related functions in the development version of zoo do
work with ordinary vectors and matrices:
> # install development version of zoo
> install.packages("zoo", repos = "http://r-forge.r-project.org";)
>
> library(zoo)
> rollmean(1:10, 2)
[1] 1.5 2.5 3.5 4.5 5.5 6.5 7.5 8.5 9.5
> rollapply(1:10, 2, sum)
[1] 3 5 7 9 11 13 15 17 19
> rollmean(1:10, 2)
[1] 1.5 2.5 3.5 4.5 5.5 6.5 7.5 8.5 9.5
> rollapply(cbind(a = 1:10, b = 11:20), 3, sum)
a b
[1,] 6 36
[2,] 9 39
[3,] 12 42
[4,] 15 45
[5,] 18 48
[6,] 21 51
[7,] 24 54
[8,] 27 57
--
Statistics & Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] "warning: assignment discards qualifiers from pointer target type"
On 07/06/2011 9:08 AM, oliver wrote:
Hello,
following an advice here from the list I looked into sources of other
packages (xts) and found the TYPEOF() macro/function, which really is
helpful.
I iused the follwong code snippet:
switch( TYPEOF( filename_sexp ) )
{
case STRSXP: filename = CHAR( STRING_ELT(filename_sexp, 0) );
break;
default: error("filename argument must be a string");
break;
}
Here, filename is of type char*
and one function opens a file with that name.
So it is purely intended to just grab out the char* from the
String-Expression.
Am I doing something wrong here, or is it ok, but I have somehow
to say the extracting macros/functions, that it is really intended
to throw away information and that a warning is not necessary?
The result of calling CHAR should be a "const char *". You are not
allowed to touch the string it points to.
Duncan Murdoch
__
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?
Thanks for the answer! Sorry, must have missed that part of the help
page. Your second approach is exactly what I was looking for.
Regards,
Janko
On 06.06.2011 23:38, John Chambers wrote:
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
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Packages for R-CRAN (organizing aspects)
On Tue, Jun 07, 2011 at 10:30:12AM -0400, Gabor Grothendieck wrote:
> On Tue, Jun 7, 2011 at 9:03 AM, oliver wrote:
> > Hello,
> >
> > I have some ideas for packages that I want to provide on R-CRAN.
> >
> > One package alreads is working, but I have some warnings in
> > when compiling. Also I don't know if the libraries in use are only
> > working on Unix/Linux.
> >
> > So I have some general questions:
> >
> > - If I'm not sure if the code would also work on windows
> > (needing some ceratain libraries or tools),
> > would it be better to mark it as Unix-like only?
> >
> > Would other people, who are interested in using the package
> > on Windows, then look for the other issues?
> >
> > (I'm just interested in providing the functionality, and I don't use
> > Windows,
> > so compatibility would not be my main goal, if it's using certain
> > libraries;
> > but if the code is not relying on certain libs or tools I of course
> > write
> > code ANSI-conform, so that it *should* compile on windows too.)
> >
> > I mean: I just want to have the work for Unix/Linux, but in general like
> > the
> > platform-independent approach. I just have no interest, looking at the
> > windows
> > side too much. Are there people from R-CRAN team, who help at that point
> > to make
> > things available on many platforms?
> >
> >
> > - I have in mind packages for reading a lot of different files /
> > fileformat.
> > How to name them?
> > it would be consequent to name them
> > read.
> > but I'm not sure if this naming style is reserved for OO-methods only,
> > and that topic I will learn later in detail, so that at the moment
> > I just would provide the raw functionality.
> >
> > Maybe the name of the reading function should then better be named
> > read or read ?
> >
> > - There are a lot of different fileformats that I want to read in.
> >
> > Would it be better to make for each format one different package,
> > or rather put them all together as a package "Readmisc"?
> >
> > For example the following formats I have in mind:
> >
> > - jpeg (libjpeg62) => already working, I want to
> > clean up the code and
> > documentation
> > soon and then provide on
> > R-CRAN
> >
>
> Note existence of read.jpeg in the rimage package, read.gif in the
> caTools package and readPNG in the png package.
read.jpeg in rimage does not give me a matrix like I would extpect in R,
for further working with the data.
It gives me an imagmatrix, which's value I can't access directly.
I only have a data structure that is closed to the functionality that the
rimage module provides.
Maybe I have overseen something,
but how would I plot a histogram
of R, G and B values and the according
grayvalue's histogram?
With my libjpeg reader it would be:
library(libjpeg)
pic <- readjpeg( picfilename )
par(mfrof=c(4,1))
hist( pic$r, breaks = 256, col="red")
hist( pic$g, breaks = 256, col="green")
hist( pic$b, breaks = 256, col="blue")
hist( pic$bw, breaks = 256)
How would that be possible with rimage?
read.gif in caTools is giving back a matrix, and hence it's a fine function.
caTools btw. offers a lot of very interesting functions. :-)
readPNG of png package is agood hint,
I didn't knew that.
>
> > - bvh (maybe (f)lex or yacc or pcre) => want to start this soon
> >
> > - apachelogfile /maybe using pcre) => starting date not planned
> >
> > - some other formats also
> >
> >
> > - Other package ideas: rolling application (which uses R's built in types,
> > not like zoo() using special types)
>
> rollapply and related functions in the development version of zoo do
> work with ordinary vectors and matrices:
Ah the it's a new feature, which is not offered in the packages I can install
with install.packages and the default settings for this.
I had to use as.zoo() around my data to use rollapply from zoo-package.
> # install development version of zoo
> install.packages("zoo", repos = "http://r-forge.r-project.org";)
Aha.
OK, thanks.
What about the documentation.
if I look for it on r-cran, but the module is form r-forge there will
be a mismatch.
> >
> > library(zoo)
> > rollmean(1:10, 2)
> [1] 1.5 2.5 3.5 4.5 5.5 6.5 7.5 8.5 9.5
> > rollapply(1:10, 2, sum)
> [1] 3 5 7 9 11 13 15 17 19
> > rollmean(1:10, 2)
> [1] 1.5 2.5 3.5 4.5 5.5 6.5 7.5 8.5 9.5
> > rollapply(cbind(a = 1:10, b = 11:20), 3, sum)
Yes, with that version it works. :-)
Ciao,
Oliver
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Packages for R-CRAN (organizing aspects)
On Tue, Jun 7, 2011 at 12:00 PM, oliver wrote: > > What about the documentation. > if I look for it on r-cran, but the module is form r-forge there will > be a mismatch. ?, vignette(...) and library(help=...) will give help that corresponds to the package you installed. -- Statistics & Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Overloading S4 methods
Yes, Dylan is in many ways more authoritarian than R! Possibly also
with fewer users to be annoyed.
We might go to a warning as Iago suggests. If we did add a warning, it
would be likely be more useful in the setMethod() call than at CMD check
time, after the package has been designed and implemented.
John
On 6/7/11 6:15 AM, luke-tier...@uiowa.edu wrote:
On Mon, 6 Jun 2011, John Chambers wrote:
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.
Dylan is simliar in using a generic funciton model. One of the Dylan
books -- I forget which one -- strongly recomends that a library only
define a method if either it also defines the generic or if it defines
one of the classes the method is specialized on. THis isn't an enforced
requirement but a strong recommendation.
Best,
luke
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 e
Re: [Rd] Overloading S4 methods
On Tue, 7 Jun 2011, John Chambers wrote:
Yes, Dylan is in many ways more authoritarian than R! Possibly also with
fewer users to be annoyed.
Huh? A convention in a programming book is more authoritarian than a
warning as you are proposing (not that I am opposed to that -- I think
it's probably idea)?
Number of users of Dylan is definitely smaller, especially now, but
level of academic-level CS involvement in language design is
not. There is a lot of work in that literature that really is worth
looking at.
Best,
luke
We might go to a warning as Iago suggests. If we did add a warning, it would
be likely be more useful in the setMethod() call than at CMD check time,
after the package has been designed and implemented.
John
On 6/7/11 6:15 AM, luke-tier...@uiowa.edu wrote:
On Mon, 6 Jun 2011, John Chambers wrote:
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.
Dylan is simliar in using a generic funciton model. One of the Dylan
books -- I forget which one -- strongly recomends that a library only
define a method if either it also defines the generic or if it defines
one of the classes the method is specialized on. THis isn't an enforced
requirement but a strong recommendation.
Best,
luke
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
Re: [Rd] Overloading S4 methods
Can then the warning be turned off in any way to avoid it showing up
on check? Maybe an argument to confirm 'I know what I am doing so I
need no warning, thank you very much'.
Iago
On Tue, Jun 7, 2011 at 7:06 PM, John Chambers wrote:
> Yes, Dylan is in many ways more authoritarian than R! Possibly also with
> fewer users to be annoyed.
>
> We might go to a warning as Iago suggests. If we did add a warning, it
> would be likely be more useful in the setMethod() call than at CMD check
> time, after the package has been designed and implemented.
>
> John
>
> On 6/7/11 6:15 AM, luke-tier...@uiowa.edu wrote:
>>
>> On Mon, 6 Jun 2011, John Chambers wrote:
>>
>>> 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.
>>
>> Dylan is simliar in using a generic funciton model. One of the Dylan
>> books -- I forget which one -- strongly recomends that a library only
>> define a method if either it also defines the generic or if it defines
>> one of the classes the method is specialized on. THis isn't an enforced
>> requirement but a strong recommendation.
>>
>> Best,
>>
>> luke
>>
>>>
>>> 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 o
Re: [Rd] Overloading S4 methods
On 6/7/11 2:02 PM, Iago Mosqueira wrote:
Can then the warning be turned off in any way to avoid it showing up
on check? Maybe an argument to confirm 'I know what I am doing so I
need no warning, thank you very much'.
Well, this is still new territory since the bug didn't seem to have been
encountered before your example. We won't add the warning in the
immediate future, and as Luke pointed out, even Dylan just advises.
This may be more a matter for a "code tools" approach. So not to worry
just yet!
John
Iago
On Tue, Jun 7, 2011 at 7:06 PM, John Chambers wrote:
Yes, Dylan is in many ways more authoritarian than R! Possibly also with
fewer users to be annoyed.
We might go to a warning as Iago suggests. If we did add a warning, it
would be likely be more useful in the setMethod() call than at CMD check
time, after the package has been designed and implemented.
John
On 6/7/11 6:15 AM, luke-tier...@uiowa.edu wrote:
On Mon, 6 Jun 2011, John Chambers wrote:
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.
Dylan is simliar in using a generic funciton model. One of the Dylan
books -- I forget which one -- strongly recomends that a library only
define a method if either it also defines the generic or if it defines
one of the classes the method is specialized on. THis isn't an enforced
requirement but a strong recommendation.
Best,
luke
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
