Re: [Rd] Missing args with a default value in S4 methods
This has essentially nothing to do with methods, but rather with the
treatment of missing arguments.
Consider:
> foo <- function(x,...)bar(x,...)
> bar <- function(x, y=12, z, ...) {cat(missing(y), "\n"); cat(y, "\n")}
This is the same argument-matching as your example, since the generic
and method have different formal arguments. And indeed,
> foo("a",,z=99)
TRUE
Error in cat(y, "\n") : argument is missing, with no default
The error message is correct, but the argument in question is not "y"
but "..1". This is constructed and passed down as a special R object
representing "missing-argument-with-no-default". (Splus would have
worked as you expected, because missingness there is a property of the
function call, not of the object corresponding to the formal argument.)
Herve Pages wrote:
> Hi,
>
>
> Strange things happen with missing args in S4 methods:
>
> > setGeneric("mygen", signature="x", function(x, ...)
> standardGeneric("mygen"))
> [1] "mygen"
>
> > setMethod("mygen", "character", function(x, y=12, z, ...)
> {cat(missing(y), "\n"); cat(y, "\n")})
> [1] "mygen"
>
> > mygen("aa", z=99)
> TRUE
> 12
>
> > mygen("aa", , 99)
> TRUE
> Error in cat(y, "\n") : argument is missing, with no default
> ^^^ ^^
>TRUE NOT TRUE!
>
>
> For "normal" functions, things work as expected:
>
> > myfun <- function(x, y=12, z, ...) {cat(missing(y), "\n"); cat(y, "\n")}
>
> > myfun("aa", z=99)
> TRUE
> 12
>
> > myfun("aa", , 99)
> TRUE
> 12
>
> And with S3 generics too:
>
> > dd <- data.frame(aa=letters[1:9], ii=9:1)
> > head(dd, z="ignored")
> aa ii
> 1 a 9
> 2 b 8
> 3 c 7
> 4 d 6
> 5 e 5
> 6 f 4
>
> > head(dd, , "ignored")
> aa ii
> 1 a 9
> 2 b 8
> 3 c 7
> 4 d 6
> 5 e 5
> 6 f 4
>
> Cheers,
> H.
>
> __
> 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] readchar() bug or feature? was Re: Clarification for readChar man page
Jeffrey Horner wrote:
> Jeffrey Horner wrote:
>> Duncan Murdoch wrote:
>>> On 6/14/2007 10:49 AM, Jeffrey Horner wrote:
Hi,
Here's a patch to the readChar manual page (R-trunk as of today)
that better clarifies readChar's return value.
>>> Your update is not right. For example:
>>>
>>> x <- as.raw(32:96)
>>> readChar(x, nchars=rep(2,100))
>>>
>>> This returns a character vector of length 100, of which the first 32
>>> elements have 2 chars, the next one has 1, and the rest are "".
>>>
>>> So the length of nchars really does affect the length of the value.
>>>
>>> Now, I haven't looked at the code, but it's possible we could delete
>>> the "(which might be less than \code{length(nchars)})" remark, and if
>>> not, it would be useful to explain the situations in which the return
>>> value could be shorter than the nchars vector.
>>
>> Well, this is rather a misunderstanding on my part; I completely
>> forgot about vectorization. The manual page makes sense to me now.
>>
>> But the situation about the return value possibly being less than
>> length(nchars) isn't clear. Consider a 101 byte text file in a
>> non-multibyte character locale:
>>
>> f <- tempfile()
>> writeChar(paste(rep(seq(0,9),10),collapse=''),con=f)
>>
>> and calling readChar() to read 100 bytes with length(nchar)=10:
>>
>> > readChar(f,nchar=rep(10,10))
>> [1] "0123456789" "0123456789" "0123456789" "0123456789" "0123456789"
>> [6] "0123456789" "0123456789" "0123456789" "0123456789" "0123456789"
>>
>> and readChar() reading the entire file with length(nchar)=11:
>>
>> > readChar(f,nchar=rep(10,11))
>> [1] "0123456789" "0123456789" "0123456789" "0123456789" "0123456789"
>> [6] "0123456789" "0123456789" "0123456789" "0123456789" "0123456789"
>> [11] "\0"
>>
>> but the following two outputs are confusing. readchar() with
>> length(nchar)>=12 returns a character vector length 12:
>>
>> > readChar(f,nchar=rep(10,12))
>> [1] "0123456789" "0123456789" "0123456789" "0123456789" "0123456789"
>> [6] "0123456789" "0123456789" "0123456789" "0123456789" "0123456789"
>> [11] "\0" ""
>> > readChar(f,nchar=rep(10,13))
>> [1] "0123456789" "0123456789" "0123456789" "0123456789" "0123456789"
>> [6] "0123456789" "0123456789" "0123456789" "0123456789" "0123456789"
>> [11] "\0" ""
>>
>> It seems that the first time EOF is encountered on a read operation,
>> an empty string is returned, but on subsequent reads nothing is
>> returned. Is this intended behavior?
>
> I believe this is an off-by-1 bug in do_readchar(). The following fix to
> R-trunk v41946 causes the above readchar() calls to cap the returned
> vector length at 11:
>
> Index: src/main/connections.c
> ===
> --- src/main/connections.c (revision 41946)
> +++ src/main/connections.c (working copy)
> @@ -3286,7 +3286,7 @@
> if(!con->open(con)) error(_("cannot open the connection"));
> }
> PROTECT(ans = allocVector(STRSXP, n));
> -for(i = 0, m = i+1; i < n; i++) {
> +for(i = 0, m = 0; i < n; i++) {
> len = INTEGER(nchars)[i];
> if(len == NA_INTEGER || len < 0)
> error(_("invalid value for '%s'"), "nchar");
>
This does look like an off-by-1 bug as do_readbin's for loops are coded
just like the above patch.
Jeff
--
http://biostat.mc.vanderbilt.edu/JeffreyHorner
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] LAPACK Headers
Prof. Ripley,
I had a feeling I was going a little too deep into the R source code
in order to pull out these functions. I particularly like these La_*
functions calling the LAPACK routines, because they have so much of
the error checking already built-in. I can just copy the code over,
and hopefully it will pick up everything in my package, but I do have
two questions.
1. I seem to vaguely recall that the R-ext documentation mentions
that routines such as this could possibly change. So if someone
wants to use any of the LAPACK or BLAS routines in their source
code, they should really only refer to the programs in
R_ext/Lapack.h?
2. I think the LAPACK utilities are key in R, and help new
researchers avoid having to use proprietary code such as Numerical
Recipes when doing their research. Is there a reason why code
such as the La_* wrapper functions are not ``public''? I really
think they're quite useful.
Thanks,
Brian
On Fri, Jun 15, 2007 at 06:45:09AM +0100, Prof Brian Ripley wrote:
> He wants "La_dgesv", which is not an LAPACK entry point at all, but a
> private part of R. The header it is in is private and not installed.
>
> There is no guarantee that it will remain visible to an R package, and the
> only safe thing to do is to copy the code.
>
> On Thu, 14 Jun 2007, [EMAIL PROTECTED] wrote:
>
> >On Thu, Jun 14, 2007 at 11:27:44PM +0100, Hin-Tak Leung wrote:
> >>Try this? (this is on 2.5.0, I don't use 2.4.x anymore)
> >>
> >>#include
> >>
> >
> >I tried this, but I still get the warning of implicit declaration of
> >function. It does compile though.
> >
> >>Have you actually tried grep dgesv $R_HOME/include/* $R_HOME/include/*/*
> >>to see which file to include for dgesv ??
> >
> >Well, when I grep the R source files, I get:
> >
> >$ find . -name "*" -print | xargs grep -i 'La_dgesv'
> >./src/main/basedecl.h:SEXP La_dgesv(SEXP, SEXP, SEXP);
> >./src/main/lapack.c:SEXP La_dgesv(SEXP A, SEXP B, SEXP tol)
> >./src/main/lapack.c:SEXP La_dgesv(SEXP A, SEXP B, SEXP tol)
> >./src/main/registration.c:CALLDEF(La_dgesv, 3),
> >./src/library/base/R/solve.R: .Call("La_dgesv", a, b, tol, PACKAGE
> >= "base")
> >./src/library/base/R/solve.R: drop(.Call("La_dgesv", a,
> >as.matrix(b), tol, PACKAGE = "base")))
> >./src/modules/lapack/Lapack.c:static SEXP modLa_dgesv(SEXP A, SEXP
> >Bin, SEXP tolin)
> >./src/modules/lapack/Lapack.c:tmp->dgesv = modLa_dgesv;
> >./src/include/Rmodules/Rlapack.h:typedef SEXP (*Rf_La_dgesv)(SEXP A,
> >SEXP B, SEXP tol);
> >./src/include/Rmodules/Rlapack.h:Rf_La_dgesv dgesv;
> >
> >So it looks like La_dgesv is declared in basedecl.h, but I don't see
> >this file anywhere else on my machine. Maybe I shouldn't be using
> >this function in my package?
> >
> >
> >
> >>
> >>HTL
> >>
> >>[EMAIL PROTECTED] wrote:
> >>>Hey Everyone,
> >>>
> >>>I'm running R 2.4.0 on Debian etch 4.0, and I'm trying to call some
> >>>LAPACK functions from the C code in my package. Actually, to be
> >>>honest I'm not really having trouble using commands such as La_dgesv
> >>>from within my C code, but I do get warning when compiling the package
> >>>saying:
> >>>
> >>>***.c: In function '***':
> >>>***.c:37: warning: implicit declaration of function 'La_dgesv'
> >>>***.c:37: warning: assignment makes pointer from integer without
> >>>a cast
> >>>
> >>>I tried using:
> >>>
> >>>#include
> >>>
> >>>but it won't compile the package at all with that included,
> >>>complaining that
> >>>
> >>>***.h:5:30: error: Rmodules/Rlapack.h: No such file or directory
> >>>
> >>>Can someone explain to me how I should include the headers to this
> >>>AWESOME wrapper code to the LAPACK libraries? Am I not following the
> >>>proper protocol by using these La_* commands in my package source
> >>>code?
> >>>
> >>>Note, I also have the following in Makevars
> >>>
> >>>PKG_LIBS = $(LAPACK_LIBS) $(BLAS_LIBS) $(FLIBS)
> >>>
> >>>TIA!
> >>>
> >>>I initially posted this question on the general list, but I didn't get
> >>>any responses.
> >>>
> >>>__
> >>>R-devel@r-project.org mailing list
> >>>https://stat.ethz.ch/mailman/listinfo/r-devel
> >>
> >
> >
>
> --
> Brian D. Ripley, [EMAIL PROTECTED]
> 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
--
Brian J. Lopes
PhD Student
Department of Statistics and Operations Research
University of North Carolina at Chapel Hill
To know that we know what we know, and that we do not know what we do
not know, that is true knowledge --Henry David Thoreau (quoting
Confucius): Walden
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] LAPACK Headers
On Fri, 15 Jun 2007, [EMAIL PROTECTED] wrote:
> Prof. Ripley,
>
> I had a feeling I was going a little too deep into the R source code
> in order to pull out these functions. I particularly like these La_*
> functions calling the LAPACK routines, because they have so much of
> the error checking already built-in. I can just copy the code over,
> and hopefully it will pick up everything in my package, but I do have
> two questions.
>
> 1. I seem to vaguely recall that the R-ext documentation mentions
>that routines such as this could possibly change. So if someone
>wants to use any of the LAPACK or BLAS routines in their source
>code, they should really only refer to the programs in
>R_ext/Lapack.h?
Yes.
> 2. I think the LAPACK utilities are key in R, and help new
>researchers avoid having to use proprietary code such as Numerical
>Recipes when doing their research. Is there a reason why code
>such as the La_* wrapper functions are not ``public''? I really
>think they're quite useful.
They are private, and the R developers must be free to change R internals
as they need to. If we made public everything that anyone wanted to use,
we would never be able to improve R (and we would spend all our time
answering questions about private structures).
Also, having a large set of entry points that are accessible is a
performance hit for every R session. We've have about half hidden on
platforms which support this, and we are likely to hide more (including
these).
>
> Thanks,
> Brian
>
>
> On Fri, Jun 15, 2007 at 06:45:09AM +0100, Prof Brian Ripley wrote:
>> He wants "La_dgesv", which is not an LAPACK entry point at all, but a
>> private part of R. The header it is in is private and not installed.
>>
>> There is no guarantee that it will remain visible to an R package, and the
>> only safe thing to do is to copy the code.
>>
>> On Thu, 14 Jun 2007, [EMAIL PROTECTED] wrote:
>>
>>> On Thu, Jun 14, 2007 at 11:27:44PM +0100, Hin-Tak Leung wrote:
Try this? (this is on 2.5.0, I don't use 2.4.x anymore)
#include
>>>
>>> I tried this, but I still get the warning of implicit declaration of
>>> function. It does compile though.
>>>
Have you actually tried grep dgesv $R_HOME/include/* $R_HOME/include/*/*
to see which file to include for dgesv ??
>>>
>>> Well, when I grep the R source files, I get:
>>>
>>> $ find . -name "*" -print | xargs grep -i 'La_dgesv'
>>> ./src/main/basedecl.h:SEXP La_dgesv(SEXP, SEXP, SEXP);
>>> ./src/main/lapack.c:SEXP La_dgesv(SEXP A, SEXP B, SEXP tol)
>>> ./src/main/lapack.c:SEXP La_dgesv(SEXP A, SEXP B, SEXP tol)
>>> ./src/main/registration.c:CALLDEF(La_dgesv, 3),
>>> ./src/library/base/R/solve.R: .Call("La_dgesv", a, b, tol, PACKAGE
>>> = "base")
>>> ./src/library/base/R/solve.R: drop(.Call("La_dgesv", a,
>>> as.matrix(b), tol, PACKAGE = "base")))
>>> ./src/modules/lapack/Lapack.c:static SEXP modLa_dgesv(SEXP A, SEXP
>>> Bin, SEXP tolin)
>>> ./src/modules/lapack/Lapack.c:tmp->dgesv = modLa_dgesv;
>>> ./src/include/Rmodules/Rlapack.h:typedef SEXP (*Rf_La_dgesv)(SEXP A,
>>> SEXP B, SEXP tol);
>>> ./src/include/Rmodules/Rlapack.h:Rf_La_dgesv dgesv;
>>>
>>> So it looks like La_dgesv is declared in basedecl.h, but I don't see
>>> this file anywhere else on my machine. Maybe I shouldn't be using
>>> this function in my package?
>>>
>>>
>>>
HTL
[EMAIL PROTECTED] wrote:
> Hey Everyone,
>
> I'm running R 2.4.0 on Debian etch 4.0, and I'm trying to call some
> LAPACK functions from the C code in my package. Actually, to be
> honest I'm not really having trouble using commands such as La_dgesv
> from within my C code, but I do get warning when compiling the package
> saying:
>
> ***.c: In function '***':
> ***.c:37: warning: implicit declaration of function 'La_dgesv'
> ***.c:37: warning: assignment makes pointer from integer without
> a cast
>
> I tried using:
>
> #include
>
> but it won't compile the package at all with that included,
> complaining that
>
> ***.h:5:30: error: Rmodules/Rlapack.h: No such file or directory
>
> Can someone explain to me how I should include the headers to this
> AWESOME wrapper code to the LAPACK libraries? Am I not following the
> proper protocol by using these La_* commands in my package source
> code?
>
> Note, I also have the following in Makevars
>
> PKG_LIBS = $(LAPACK_LIBS) $(BLAS_LIBS) $(FLIBS)
>
> TIA!
>
> I initially posted this question on the general list, but I didn't get
> any responses.
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>>
>>
>> --
>> Brian D. Ripley, [EMAIL PROTECTED]
>> Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
>> University of
[Rd] NaN in crossprod
Hello,
I have come across a troubling problem in which my call to crossprod
will occasionally produce NaNs. That is, a proper matrix cross-product
will be produced except that some of the matrix elements will
arbitrarily be NaN. For my purposes, this is extremely bad. On several
different R sessions run this morning this example below may fail a few
times out of a million, though sometimes not at all.
> x <- matrix(1, 100, 100); w <- rep(1, 100)
> for(i in 1:100) if(any(is.na(crossprod(w,x cat("!")
Unfortunately, this error has been hard to reproduce as I was finding
frequent NaNs produced an hour ago but am not finding any such cases
now. I'm using a shared network computer so it's possible the computer
was under different resource constraints when the problem occurred. I
compiled R 2.5.0 on an Intel Xeon(P4) processor running Linux
2.4.21-47.0.1 on Red Hat AS 3.0, with ATLAS 3.7.30 BLAS support.
My _guess_ is that the problem is on the ATLAS end (bug, bad
compilation, etc.), though as I can't seem to reproduce the problem in
the past hour, I'm not sure I'd even know if I had "fixed" it by using a
different version of ATLAS, or recompiling, etc. And not being quite
sure how crossprod works internally, my guess is not even an educated
one. So, lest the NaNs be a symptom of impending hardware failure, solar
flares, or even a "mis-feature" in R, I thought I'd solicit any
comments, ideas, and suggestions this group might have.
Thanks,
Robert
> R.version _
platform i686-pc-linux-gnu
arch i686
os linux-gnu
system i686, linux-gnu
status
major 2
minor 5.0
year 2007
month 04
day23
svn rev41293
language R
version.string R version 2.5.0 (2007-04-23)
Robert McGehee, CFA
Quantitative Analyst
Geode Capital Management, LLC
One Post Office Square, 28th Floor | Boston, MA | 02109
Tel: 617/392-8396Fax:617/476-6389
mailto:[EMAIL PROTECTED]
This e-mail, and any attachments hereto, are intended for us...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Missing args with a default value in S4 methods
John Chambers wrote:
> This has essentially nothing to do with methods, but rather with the
> treatment of missing arguments.
>
> Consider:
>> foo <- function(x,...)bar(x,...)
>> bar <- function(x, y=12, z, ...) {cat(missing(y), "\n"); cat(y, "\n")}
>
> This is the same argument-matching as your example, since the generic
> and method have different formal arguments. And indeed,
>
>> foo("a",,z=99)
> TRUE
> Error in cat(y, "\n") : argument is missing, with no default
>
> The error message is correct, but the argument in question is not "y"
> but "..1". This is constructed and passed down as a special R object
> representing "missing-argument-with-no-default". (Splus would have
> worked as you expected, because missingness there is a property of the
> function call, not of the object corresponding to the formal argument.)
Thanks John for the clarification! I can see why, _technically speaking_, things
behave how they behave.
Note that what happens with default arguments in methods is not always the same
as with normal functions so it's not always possible to predict what is actually
going to happen... Here is an example:
1) Default arg in the method:
o generic + method:
> bar <- function(x, y=12, z) {cat(missing(y), "\n"); cat(x, y, z, "\n")}
> setGeneric("mygen", signature=c("x", "z"), function(x, y, z)
standardGeneric("mygen"))
> setMethod("mygen", c("ANY", "ANY"), bar)
> mygen("aa", , "bb")
TRUE
Error in cat(x, y, z, "\n") : argument "y" is missing, with no default
o normal functions:
> foo <- function(x, y, z) bar(x, y, z)
> foo("aa", ,"bb")
TRUE
Error in cat(x, y, z, "\n") : argument "y" is missing, with no default
Behaviour is the same.
2) Default arg in the generic:
o generic + method: example 1) shows that if I want a default value
for y, it should be put in the generic rather than in the method:
> bar <- function(x, y, z) {cat(missing(y), "\n"); cat(x, y, z, "\n")}
> setGeneric("mygen", signature=c("x", "z"), function(x, y=12, z)
standardGeneric("mygen"))
> setMethod("mygen", c("ANY", "ANY"), bar)
> mygen("aa", , "bb")
TRUE
aa 12 bb
o normal functions:
> foo <- function(x, y=12, z) bar(x, y, z)
> foo("aa", ,"bb")
FALSE
aa 12 bb
Behaviour is _almost_ the same!
3) Default arg in the generic _and_ in the method:
o generic + method:
> bar <- function(x, y=999, z) {cat(missing(y), "\n"); cat(x, y, z, "\n")}
> setMethod("mygen", c("ANY", "ANY"), bar)
> mygen("aa", , "bb")
TRUE
aa 999 bb
Not what I would expect!
o normal functions:
> foo("aa", ,"bb")
FALSE
aa 12 bb
Much better.
I'm sure there is a _technical_ explanation for this (with probably some lazy
evaluation
involved) but I find the current behaviour confusing and very hard to predict.
Cheers,
H.
>
>
> Herve Pages wrote:
>> Hi,
>>
>>
>> Strange things happen with missing args in S4 methods:
>>
>> > setGeneric("mygen", signature="x", function(x, ...)
>> standardGeneric("mygen"))
>> [1] "mygen"
>>
>> > setMethod("mygen", "character", function(x, y=12, z, ...)
>> {cat(missing(y), "\n"); cat(y, "\n")})
>> [1] "mygen"
>>
>> > mygen("aa", z=99)
>> TRUE
>> 12
>>
>> > mygen("aa", , 99)
>> TRUE
>> Error in cat(y, "\n") : argument is missing, with no default
>> ^^^ ^^
>>TRUE NOT TRUE!
>>
>>
>> For "normal" functions, things work as expected:
>>
>> > myfun <- function(x, y=12, z, ...) {cat(missing(y), "\n"); cat(y,
>> "\n")}
>>
>> > myfun("aa", z=99)
>> TRUE
>> 12
>>
>> > myfun("aa", , 99)
>> TRUE
>> 12
>>
>> And with S3 generics too:
>>
>> > dd <- data.frame(aa=letters[1:9], ii=9:1)
>> > head(dd, z="ignored")
>> aa ii
>> 1 a 9
>> 2 b 8
>> 3 c 7
>> 4 d 6
>> 5 e 5
>> 6 f 4
>>
>> > head(dd, , "ignored")
>> aa ii
>> 1 a 9
>> 2 b 8
>> 3 c 7
>> 4 d 6
>> 5 e 5
>> 6 f 4
>>
>> Cheers,
>> H.
>>
>> __
>> 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
