Re: [Rd] promptClass misses methods
> "RossB" == Ross Boylan <[EMAIL PROTECTED]>
> on Fri, 1 Dec 2006 11:33:21 -0800 writes:
RossB> On Fri, Dec 01, 2006 at 11:37:46AM +0100, Martin
RossB> Maechler wrote:
>> > "RossB" == Ross Boylan <[EMAIL PROTECTED]>
>> > on Thu, 30 Nov 2006 22:29:06 -0800 writes:
>>
RossB> I've had repeated problems with promptClass missing
RossB> methods, usually telling me a class has no methods
RossB> when it does.
>>
RossB> In my current case, I've defined an S4 class
RossB> "mspathCoefficients" with a print method
RossB> setMethod("print", signature(x="mspathCoefficients"),
RossB> function(x, ...) { # etc
>> You should *not* define "print" methods for S4 classes;
>> rather you should define "show" methods.
RossB> Is that because print is used by the S3 system?
no, not really.
RossB> And is the general rule to avoid using S3 methods for S4
RossB> classes?
Well your wording is murky, but no, you *should* define (S4) methods
for S3 generics very well. The S3 generics are automagically
promoted to S4 generics as soon as you define an S4 method for it.
print() is just a big exception.
RossB> For example, http://www.omegahat.org/RSMethods/Intro.pdf, which is
RossB> referenced in the package help for methods, discusses
RossB> show, print and plot as 3 alternatives in S4 (p. 9,
RossB> though a footnote says that at that time--2001--R
RossB> didn't recognize formal methods for printing
RossB> objects.)
2001 is way in the past concerning S4 implementation in R.
Specifically, using S4 in R; we'd **very strongly** recommend
R 2.4.0 (and ideally even R-patched) because of several recent
good developments.
RossB> I've been unable to locate much information about
RossB> combining S3 and S4 methods, though I recall seeing a
RossB> note saying this issue was still to be addressed in
RossB> R. Perhaps it has been now, with setOldClass? At
RossB> any rate, the help for that method addresses classes
RossB> rather than methods, and I didn't see anything in
RossB> ?Methods, ?setMethod, or ?setGeneric.
RossB> show() raises two additional issues for me. First,
RossB> it takes a single argument, and I want to be able to
RossB> pass in additional arguments via ... .
That's not possible currently.
And I agree that in certain cases, I would want to have the
flexibility of print(..) there;
One case is for printing/showing fitted LMER objects; the
following code is used :
## This is modeled a bit after print.summary.lm :
printMer <- function(x, digits = max(3, getOption("digits") - 3),
correlation = TRUE, symbolic.cor = x$symbolic.cor,
signif.stars = getOption("show.signif.stars"), ...)
{
...
...
invisible(x)
}
setMethod("print", "mer", printMer)
setMethod("show", "mer", function(object) printMer(object))
RossB> Second, I read some advice somewhere, that I no
RossB> longer can find, that show methods should return an
RossB> object and that object in turn should be the thing
RossB> that is printed. I don't understand the motivation
RossB> for that rule, at least in this case, because my
RossB> object is already a results object.
I think you're confusing show() with summary(): The latter is
should typically compute an object which then has a print/show method.
RossB> The file promptClass creates has no methods in it.
>> >> showMethods(classes="mspathCoefficients")
RossB> Function: initialize (package methods)
RossB> .Object="mspathCoefficients" (inherited from:
RossB> .Object="ANY")
>> so it's just inherited from "ANY"
>>
RossB> Function: print (package base) x="mspathCoefficients"
>> that's the one
RossB> So why isn't promptClass picking it up?
>>
RossB> Function: show (package methods)
RossB> object="mspathCoefficients" (inherited from:
RossB> object="ANY")
>> so it's just inherited from "ANY"
>>
>> Ross, it would really be more polite to your readers if
>> you followed the posting guide and posted complete
>> fully-reproducible code...
RossB> I thought it might be overkill in this case.
It never is. We do want self-contained executable code..
In your case, I assumed it might have been things in a namespace
in a package, ...
RossB> At any rate, it sounds as if I may be trying to do the wrong
RossB> thing, so I'd appreciate guidance on what the right
RossB> thing to do is.
RossB> Here's a toy example:
RossB> setClass("A", representation(x="numeric"))
RossB> setMethod("print", signature(x="A"), function(x, ...) print([EMAIL
PROTECTED], ...) )
RossB> promptClass("A")
RossB> The generated file has no print method.
Indeed, I can confirm that.
>> >> getGeneric("print")
RossB> standardGeneric for "pr
Re: [Rd] promptClass misses methods
On Sat, Dec 02, 2006 at 05:11:22PM +0100, Martin Maechler wrote:
> > "RossB" == Ross Boylan <[EMAIL PROTECTED]>
> > on Fri, 1 Dec 2006 11:33:21 -0800 writes:
>
> RossB> On Fri, Dec 01, 2006 at 11:37:46AM +0100, Martin
> RossB> Maechler wrote:
> >> > "RossB" == Ross Boylan <[EMAIL PROTECTED]>
> >> > on Thu, 30 Nov 2006 22:29:06 -0800 writes:
> >>
> RossB> I've had repeated problems with promptClass missing
> RossB> methods, usually telling me a class has no methods
> RossB> when it does.
> >>
> RossB> In my current case, I've defined an S4 class
> RossB> "mspathCoefficients" with a print method
> RossB> setMethod("print", signature(x="mspathCoefficients"),
> RossB> function(x, ...) { # etc
> >> You should *not* define "print" methods for S4 classes;
> >> rather you should define "show" methods.
>
> RossB> Is that because print is used by the S3 system?
>
> no, not really.
> RossB> And is the general rule to avoid using S3 methods for S4
> RossB> classes?
>
> Well your wording is murky, but no, you *should* define (S4) methods
> for S3 generics very well. The S3 generics are automagically
> promoted to S4 generics as soon as you define an S4 method for it.
That answers my question. The meaning was if "foo" is an S3 method,
should one avoid defining "foo" as an S4 method. And the answer is
no, it's OK. I assume one should strive to use the same argument
names, although since S3 methods don't need to use the same argument
names I'm not sure how that works (e.g. for S3
foo.class1 <- function(x, a, b) but
foo.class2 <- function(x, c)
).
>
> print() is just a big exception.
>
How come?
Is it an exception in the sense that it is not automatically used to
display the object, or in the sense that one should never define S4
print methods at all? (Looks like the first alternative based on the
example later.) The print methods I have seem to work OK, provided I
don't expect them to be called automatically and provided I don't
expect promptClass to pick them up.
> RossB> For example, http://www.omegahat.org/RSMethods/Intro.pdf, which
> is
> RossB> referenced in the package help for methods, discusses
> RossB> show, print and plot as 3 alternatives in S4 (p. 9,
> RossB> though a footnote says that at that time--2001--R
> RossB> didn't recognize formal methods for printing
> RossB> objects.)
>
> 2001 is way in the past concerning S4 implementation in R.
Perhaps the reference should be removed then. Maybe the newer
http://developer.r-project.org/howMethodsWork.pdf would be better?
However, that is pitched more toward the internals, and is already
referenced in ?Methods.
> Specifically, using S4 in R; we'd **very strongly** recommend
> R 2.4.0 (and ideally even R-patched) because of several recent
> good developments.
Fortunately that's what I'm using. I wonder if this is so important I
should require R >= 2.4 for my package. It was working fine in
earlier versions. The main user visible changes I'm aware of are
those in the object forms (i.e., binary incompatibility) and some
improvements in the algorithm for choosing which method to dispatch to
(semantically, sometimes a different method gets called; it sounds
faster too). I'm not distributing any data files with S4 class
objects, and don't have any corner cases on method dispatch.
>
> RossB> I've been unable to locate much information about
> RossB> combining S3 and S4 methods, though I recall seeing a
> RossB> note saying this issue was still to be addressed in
> RossB> R. Perhaps it has been now, with setOldClass? At
> RossB> any rate, the help for that method addresses classes
> RossB> rather than methods, and I didn't see anything in
> RossB> ?Methods, ?setMethod, or ?setGeneric.
>
> RossB> show() raises two additional issues for me. First,
> RossB> it takes a single argument, and I want to be able to
> RossB> pass in additional arguments via ... .
>
> That's not possible currently.
In the expected use of show(), namely automatically showing an object,
additional arguments don't make sense (since there's no chance to
provide them).
If the only problem in my use of print is that it's not called
automatically, then perhaps I should leave it as is and define a show
method that invokes print(). That seems to be the pattern in the
example you provided below.
>
> And I agree that in certain cases, I would want to have the
> flexibility of print(..) there;
> One case is for printing/showing fitted LMER objects; the
> following code is used :
>
> ## This is modeled a bit after print.summary.lm :
> printMer <- function(x, digits = max(3, getOption("digits") - 3),
> correlation = TRUE, symbolic.cor = x$symbolic.cor,
> signif.stars = getOption("show.signif.stars"), ...)
> {
> ...
>
Re: [Rd] promptClass misses methods
Ross Boylan <[EMAIL PROTECTED]> writes:
> That answers my question. The meaning was if "foo" is an S3 method,
> should one avoid defining "foo" as an S4 method. And the answer is
> no, it's OK. I assume one should strive to use the same argument
> names, although since S3 methods don't need to use the same argument
> names I'm not sure how that works (e.g. for S3
> foo.class1 <- function(x, a, b) but
> foo.class2 <- function(x, c)
> ).
I believe you _must_ use the same arguments. When calling
setMethod("foo", ...) where foo is a function, but not a
standardGeneric, the function foo becomes the default for a newly
created generic and the signature for the new generic is taken from
the formal arguments of the original function foo. Clear as mud?
If you want to use different argument names, then you want your own
generic. That is ok, IMO. That is why we have name spaces. It only
makes sense to set a method on an existing function (plain function,
S3, or S4 generic) if it "means" the same thing [this is obviously
fuzzy]. IMO, there is no benefit of sharing a generic or having a
default function on a generic that doesn't make sense.
Here's an example of creating a generic out of the head function:
> setClass("FOO", representation(x="character"))
[1] "FOO"
> getGeneric("head")
NULL
> args(head)
function (x, ...)
NULL
> setMethod("head", "FOO", function(x, ...) [EMAIL PROTECTED]:10])
Creating a new generic function for "head" in ".GlobalEnv"
[1] "head"
> getGeneric("head")
standardGeneric for "head" defined from package "utils"
function (x, ...)
standardGeneric("head")
Methods may be defined for arguments: x
Now head() is a good example because it means something like "show me
the first part of something". But your application might want a
function named head that meant "what's attached to the neck of an
animal". In that case, a new generic within your package's name space
seems advisable.
+ seth
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Non central chi squared bug (PR#9406)
On 12/1/2006 6:21 AM, Duncan Murdoch wrote:
> On 12/1/2006 5:44 AM, [EMAIL PROTECTED] wrote:
>> Full_Name: Alan Bain
>> Version: 2.4.0
>> OS: XP
>> Submission from: (NULL) (155.140.122.227)
>>
>>
>>
>> Code for pnchisq contains following
>>
>> if (tSml) {
>>
>> if (x> f+ theta+ 5*sqrt(2*(f+2*theta) ))){
>> return 1.; /* better than 0 --- but definately FIXME */
>> }
>>
>> }
>>
>> This needs to check which tail has been requested; it is only correct if the
>> default lower_tail=1 has been requested; for upper tail should return 0 if
>> more
>> than 5 std devs away from mean under these circumstances.
>
> Could you post a test case to demonstrate this? I don't see it:
>
> > pchisq(1000, 2, 1, FALSE)
> [1] 1.720202e-205
> > pchisq(1, 2, 1, FALSE)
> [1] 0
> > pchisq(10, 2, 1, FALSE)
> [1] 0
> > pchisq(100, 2, 1, FALSE)
> [1] 0
Offline Alan told me that this only affects ncp > 80; I've fixed it (and
a couple of other extreme cases) and will commit once testing is done.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Non central chi squared bug (PR#9406)
On 12/1/2006 6:21 AM, Duncan Murdoch wrote:
> On 12/1/2006 5:44 AM, [EMAIL PROTECTED] wrote:
>> Full_Name: Alan Bain
>> Version: 2.4.0
>> OS: XP
>> Submission from: (NULL) (155.140.122.227)
>>
>>
>>
>> Code for pnchisq contains following
>>
>> if (tSml) {
>>
>> if (x> f+ theta+ 5*sqrt(2*(f+2*theta) ))){
>> return 1.; /* better than 0 --- but definately FIXME */
>> }
>>
>> }
>>
>> This needs to check which tail has been requested; it is only correct if the
>> default lower_tail=1 has been requested; for upper tail should return 0 if
>> more
>> than 5 std devs away from mean under these circumstances.
>
> Could you post a test case to demonstrate this? I don't see it:
>
> > pchisq(1000, 2, 1, FALSE)
> [1] 1.720202e-205
> > pchisq(1, 2, 1, FALSE)
> [1] 0
> > pchisq(10, 2, 1, FALSE)
> [1] 0
> > pchisq(100, 2, 1, FALSE)
> [1] 0
Offline Alan told me that this only affects ncp > 80; I've fixed it (and
a couple of other extreme cases) and will commit once testing is done.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 2.4.1 scheduled for December 18
On 1 December 2006 at 14:00, Peter Dalgaard wrote: | The R Core Team has decided to aim for the release of 2.4.1 on Monday | December 18. This involves a feature freeze on Monday the 4th and code | freeze on Monday 11th. Automated builds of beta release and release | candidate tarballs will be available from the 5th and the 12th, | respectively. | | It is not expected that many changes will occur relative to the current | R-patched version, but as always: | | ---> Bugs reported before the release have a better chance of getting | fixed soon. <--- FWIW, a R-patched snapshot (of Nov 25) is also in Debian unstable and provides an easy one-shot 'apt-get install' way to test a new-ish R. Following past practice, I also intend to release one or two release candidates for 2.4.1 prior to its release. Regards, Dirk -- I am sorry if I replied later than usually to your email, but for the last few days Comcast acted as an Internet NON-Service provider. -- Dirk __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] passing matrix as argument to a C function
Hi,
Although this is not directly an R-related question, it is relevant as I am
trying to port some R code to C to speed things up in a computation.
I am working through my first attempts to generate and link compiled C code
in R. I could make the 'convolve' function to work and similar functions
that take vectors as arguments. In my application I need to pass a couple
of matrices to the C function and could not figure out how to make it work
in C.
As an example, I tried to code first a simple matrix-vector product
function. Here is my code:
void matrix_mult( double **A, double *b, double *ab, int *nrow, int *ncol )
{
int i, j, nr = *nrow, nc = *ncol;
for( i = 0; i < nr; i++ )
{
ab[i] = 0.0;
for( j = 0; j < nc; j++ )
ab[i] += A[i][j] * b[j];
}
}
As I understand, passing the matrix A as (double **) is not standard C and
does not compile (to try things out I am using Microsoft Visual C++ compiler
in Windows XP). I tried to find the C code for crossprod for some hints,
but could not locate it in the R source. But probably this does not use the
.C interface.
Is there a way this can be done with .C? I suspect it will use in some way
the "vector of pointers to row vectors" concept, but I am not familiar
enough in C yet to figure it out. Any hints on how in can be done with
.Call if easier?
Thank you.
-Christos
Christos Hatzis, Ph.D.
Nuvera Biosciences, Inc.
400 West Cummings Park
Suite 5350
Woburn, MA 01801
Tel: 781-938-3830
www.nuverabio.com
