[Rd] format: different S4 behavior in a package
R-Devel-ers:
I have an S4 method that simply formats an object:
setGeneric("formatMe", function(x) standardGeneric("formatMe"))
setMethod("formatMe", "ANY", function(x) format(x))
If I issue the above in an R session, then define an S4 class with its own
format method, I get the desired result:
> setClass("A",contains="numeric")
[1] "A"
> setMethod("format","A", function(x, ...) "Hey Jude")
Creating a new generic function for "format" in ".GlobalEnv"
[1] "format"
> a<-new("A",1968)
> formatMe(a)
[1] "Hey Jude"
However, if I put the two "formatMe" definitions into a package ("Test"), I
do not get the desired result.
> library(Test)
> setClass("A",contains="numeric")
[1] "A"
> setMethod("format","A", function(x, ...) "Hey Jude")
Creating a new generic function for "format" in ".GlobalEnv"
[1] "format"
> a<-new("A",1968)
> formatMe(a)
[1] "1968"
The "disconnect" does not occur, however, if the S4 format method is an S3
incarnation:
> setClass("B",contains="numeric",S3methods=TRUE)
[1] "B"
> format.B <- function(x, ...) "Don't make it bad"
> b<-new("B",1968)
> formatMe(b)
[1] "Don't make it bad"
Could the problem be in Test's NAMESPACE file? There is only one line:
exportMethods(formatMe)
Here is Test's DESCRIPTION file:
Package: Test
Type: Package
Title: Testing format
Version: 1.0
Date: 2010-06-22
Author: Dan Murphy
Maintainer: Dan Murphy
Depends: methods
Description: Does format in a package work with S4 format method?
License: GPL (>= 2)
LazyLoad: yes
(I would send the Help file, but I don't think that is the problem.)
I am using version 2.11.1 on a Windows Vista machine.
Any guidance would be appreciated. Thank you
Dan Murphy
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] format: different S4 behavior in a package
There is not a single definition of
formatMe()
in your message, therefore nothing works for me, not even the very first
version...
Best,
Uwe Ligges
On 23.06.2010 09:16, Daniel Murphy wrote:
R-Devel-ers:
I have an S4 method that simply formats an object:
setGeneric("formatMe", function(x) standardGeneric("formatMe"))
setMethod("formatMe", "ANY", function(x) format(x))
If I issue the above in an R session, then define an S4 class with its own
format method, I get the desired result:
setClass("A",contains="numeric")
[1] "A"
setMethod("format","A", function(x, ...) "Hey Jude")
Creating a new generic function for "format" in ".GlobalEnv"
[1] "format"
a<-new("A",1968)
formatMe(a)
[1] "Hey Jude"
However, if I put the two "formatMe" definitions into a package ("Test"), I
do not get the desired result.
library(Test)
setClass("A",contains="numeric")
[1] "A"
setMethod("format","A", function(x, ...) "Hey Jude")
Creating a new generic function for "format" in ".GlobalEnv"
[1] "format"
a<-new("A",1968)
formatMe(a)
[1] "1968"
The "disconnect" does not occur, however, if the S4 format method is an S3
incarnation:
setClass("B",contains="numeric",S3methods=TRUE)
[1] "B"
format.B<- function(x, ...) "Don't make it bad"
b<-new("B",1968)
formatMe(b)
[1] "Don't make it bad"
Could the problem be in Test's NAMESPACE file? There is only one line:
exportMethods(formatMe)
Here is Test's DESCRIPTION file:
Package: Test
Type: Package
Title: Testing format
Version: 1.0
Date: 2010-06-22
Author: Dan Murphy
Maintainer: Dan Murphy
Depends: methods
Description: Does format in a package work with S4 format method?
License: GPL (>= 2)
LazyLoad: yes
(I would send the Help file, but I don't think that is the problem.)
I am using version 2.11.1 on a Windows Vista machine.
Any guidance would be appreciated. Thank you
Dan Murphy
[[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] seek() and gzfile() on 32-bit R2.12.0 in linux
Brandon Whitcher wrote:
> I have installed both 32-bit and 64-bit versions of R2.12.0 (2010-06-15
> r52300) on my Ubuntu 10.04 64-bit system.
Please notice that there is NO release of R 2.12.0 until some time
around October. You are using a build from the UNSTABLE development
branch. The stable branch is 2.11.1 with a release date of May 31. If
Ubuntu is claiming that there is such a thing as a R 2.12.0 release, I'd
say that they have a problem.
Not that we don't welcome reports on problems in the development branch,
but do notice that it is by definition UNSTABLE, and that bugs can come
and go without notice.
-pd
I observe the following behavior
> when running the examples from base::connections. There appears to be a
> problem with seek() on a .gz file when using a 32-bit installation of
> R2.12.0, but the problem doesn't appear in the 64-bit installation. I
> realize that seek() has been difficult in the past, and I don't want to open
> old wounds, but is this a known problem? Is this easily fixable? I have a
> package that relies on seek() when accessing gzipped files.
>
> Using the 32-bit installation...
>
> *> zz <- file("ex.data", "w") # open an output file connection
>> cat("TITLE extra line", "2 3 5 7", "", "11 13 17", file = zz, sep =
> "\n")
>> cat("One more line\n", file = zz)
>> close(zz)
>> blah = file("ex.data", "r")
>> seek(blah)
> [1] 0
>> zz <- gzfile("ex.gz", "w") # compressed file
>> cat("TITLE extra line", "2 3 5 7", "", "11 13 17", file = zz, sep =
> "\n")
>> close(zz)
>> blah = file("ex.gz", "r")
>> seek(blah)
> [1] 7.80707e+17
>> zz <- bzfile("ex.bz2", "w") # bzip2-ed file
>> cat("TITLE extra line", "2 3 5 7", "", "11 13 17", file = zz, sep =
> "\n")
>> close(zz)
>> blah = file("ex.bz2", "r")
>> seek(blah)
> Error in seek.connection(blah) : 'seek' not enabled for this connection
>> *
>
> Using the 64-bit installation...
>
> *> zz <- file("ex.data", "w") # open an output file connection
>> cat("TITLE extra line", "2 3 5 7", "", "11 13 17", file = zz, sep = "\n")
>> cat("One more line\n", file = zz)
>> close(zz)
>> blah = file("ex.data", "r")
>> seek(blah)
> [1] 0
>> zz <- gzfile("ex.gz", "w") # compressed file
>> cat("TITLE extra line", "2 3 5 7", "", "11 13 17", file = zz, sep = "\n")
>> close(zz)
>> blah = file("ex.gz", "r")
>> seek(blah)
> [1] 0
>> zz <- bzfile("ex.bz2", "w") # bzip2-ed file
>> cat("TITLE extra line", "2 3 5 7", "", "11 13 17", file = zz, sep = "\n")
>> close(zz)
>> blah = file("ex.bz2", "r")
>> seek(blah)
> Error in seek.connection(blah) : 'seek' not enabled for this connection
>> *
>
> thanks,
>
> Brandon
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Peter Dalgaard
Center for Statistics, Copenhagen Business School
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] [R] New errors with difftime()-objects in 2.11.1 (was Re: Request: difftime method for cut())
On Wed, Jun 23, 2010 at 7:13 AM, Peter Dalgaard wrote: > Gustaf Rydevik wrote: > >> Oh, I forgot to mention that the workaround of using as.double (or >> as.numeric) works fine, and I've done that. >> It's just that it can take quite a while (as in several hours) to >> figure out that the reason for the error is that you have to force >> difftime objects to be numeric in 2.11.1, when the code's been working >> fine before and the error messages are obscure. > > I don't think you realize the problems that could occur by assuming that > difftime objects are numerics ON ANY PARTICULAR SCALE! > > -- > Peter Dalgaard > Center for Statistics, Copenhagen Business School > Phone: (+45)38153501 > Email: pd@cbs.dk Priv: pda...@gmail.com > Ah. Yes, you're right that it would be problematic to say the least to assume that the difftime object is measured in days and not in, say, seconds. And I suppose that it makes sense to prioritize avoiding calculations that give misleading results over forcing changes in old code. I was just caught somewhat unprepared, and I know that my colleagues who is not quite as R-literate will be even more unprepared for old stuff no longer working. Usually, R prepares the user for these kind of things by throwing warnings a version or two before the change is actually implemented. But I guess that's not always practical. I take it that your argument would also work agains implementing simple difftime-methods of functions as well, where you force difftime objectws to be numeric? In that case, people can disregard my suggestion of adding a difftime-method to cut(). Anyhow, I'll stop whining now. Thanks for the good work you're doing in the R Core team. Regards, Gustaf -- Gustaf Rydevik, M.Sci. tel: +46(0)703 051 451 address:Essingetorget 40,112 66 Stockholm, SE skype:gustaf_rydevik __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] seek() and gzfile() on 32-bit R2.12.0 in linux
Peter, thanks for your comments. The reason I have taken this issue to R-devel is from the advice of Kurt Hornik. An update to my package oro.nifti is being refused by CRAN because it fails on the _development_ version of R on 32-bit linux. As we have just discussed (and thanks to Matt's input), the problem is not with my package but with the development version of R. Hence, I wanted to alert to the R Core Development Team that the _unstable_ version of R appears to have a problem. Obviously, I would prefer to have my new version of oro.nifti accepted by CRAN... but at the moment I am in between a rock and a hard place. I agree that the 2.12.0 release of R is quite far in the future. Is there a possibility of relaxing the exclusion criteria for CRAN? cheers... Brandon Please notice that there is NO release of R 2.12.0 until some time around October. You are using a build from the UNSTABLE development branch. The stable branch is 2.11.1 with a release date of May 31. If Ubuntu is claiming that there is such a thing as a R 2.12.0 release, I'd say that they have a problem. Not that we don't welcome reports on problems in the development branch, but do notice that it is by definition UNSTABLE, and that bugs can come and go without notice. -pd __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] format: different S4 behavior in a package
On 06/23/2010 12:16 AM, Daniel Murphy wrote:
> R-Devel-ers:
>
> I have an S4 method that simply formats an object:
>
> setGeneric("formatMe", function(x) standardGeneric("formatMe"))
> setMethod("formatMe", "ANY", function(x) format(x))
>
> If I issue the above in an R session, then define an S4 class with its own
> format method, I get the desired result:
>
>> setClass("A",contains="numeric")
> [1] "A"
>> setMethod("format","A", function(x, ...) "Hey Jude")
> Creating a new generic function for "format" in ".GlobalEnv"
> [1] "format"
>> a<-new("A",1968)
>> formatMe(a)
> [1] "Hey Jude"
>
>
> However, if I put the two "formatMe" definitions into a package ("Test"), I
> do not get the desired result.
>
>
>> library(Test)
>> setClass("A",contains="numeric")
> [1] "A"
>> setMethod("format","A", function(x, ...) "Hey Jude")
> Creating a new generic function for "format" in ".GlobalEnv"
This is the clue -- you're creating a new S4 generic, so there's a
base::format, and a .GlobalEnv::format. Test::formatMe respects its name
space, and sees base::format.
In the S3 case, base::format is already an S3 generic, and you're just
adding a method, so there's only base::format for everyone to find.
In Test, you could setGeneric(format) and then export(format). It might
also be enough to just export(format); I'm not sure.
Martin
> [1] "format"
>> a<-new("A",1968)
>> formatMe(a)
> [1] "1968"
>
>
> The "disconnect" does not occur, however, if the S4 format method is an S3
> incarnation:
>
>> setClass("B",contains="numeric",S3methods=TRUE)
> [1] "B"
>> format.B <- function(x, ...) "Don't make it bad"
>> b<-new("B",1968)
>> formatMe(b)
> [1] "Don't make it bad"
>
> Could the problem be in Test's NAMESPACE file? There is only one line:
> exportMethods(formatMe)
>
> Here is Test's DESCRIPTION file:
> Package: Test
> Type: Package
> Title: Testing format
> Version: 1.0
> Date: 2010-06-22
> Author: Dan Murphy
> Maintainer: Dan Murphy
> Depends: methods
> Description: Does format in a package work with S4 format method?
> License: GPL (>= 2)
> LazyLoad: yes
>
> (I would send the Help file, but I don't think that is the problem.)
>
> I am using version 2.11.1 on a Windows Vista machine.
>
> Any guidance would be appreciated. Thank you
>
> Dan Murphy
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Martin Morgan
Computational Biology / Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box 19024 Seattle, WA 98109
Location: Arnold Building M1 B861
Phone: (206) 667-2793
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] format: different S4 behavior in a package
Thank you, Martin. That worked. And fyi 'export(format)' alone was not
sufficient.
Best,
Dan
On Wed, Jun 23, 2010 at 5:15 AM, Martin Morgan wrote:
> On 06/23/2010 12:16 AM, Daniel Murphy wrote:
> > R-Devel-ers:
> >
> > I have an S4 method that simply formats an object:
> >
> > setGeneric("formatMe", function(x) standardGeneric("formatMe"))
> > setMethod("formatMe", "ANY", function(x) format(x))
> >
> > If I issue the above in an R session, then define an S4 class with its
> own
> > format method, I get the desired result:
> >
> >> setClass("A",contains="numeric")
> > [1] "A"
> >> setMethod("format","A", function(x, ...) "Hey Jude")
> > Creating a new generic function for "format" in ".GlobalEnv"
> > [1] "format"
> >> a<-new("A",1968)
> >> formatMe(a)
> > [1] "Hey Jude"
> >
> >
> > However, if I put the two "formatMe" definitions into a package ("Test"),
> I
> > do not get the desired result.
> >
> >
> >> library(Test)
> >> setClass("A",contains="numeric")
> > [1] "A"
> >> setMethod("format","A", function(x, ...) "Hey Jude")
> > Creating a new generic function for "format" in ".GlobalEnv"
>
> This is the clue -- you're creating a new S4 generic, so there's a
> base::format, and a .GlobalEnv::format. Test::formatMe respects its name
> space, and sees base::format.
>
> In the S3 case, base::format is already an S3 generic, and you're just
> adding a method, so there's only base::format for everyone to find.
>
> In Test, you could setGeneric(format) and then export(format). It might
> also be enough to just export(format); I'm not sure.
>
> Martin
>
> > [1] "format"
> >> a<-new("A",1968)
> >> formatMe(a)
> > [1] "1968"
> >
> >
> > The "disconnect" does not occur, however, if the S4 format method is an
> S3
> > incarnation:
> >
> >> setClass("B",contains="numeric",S3methods=TRUE)
> > [1] "B"
> >> format.B <- function(x, ...) "Don't make it bad"
> >> b<-new("B",1968)
> >> formatMe(b)
> > [1] "Don't make it bad"
> >
> > Could the problem be in Test's NAMESPACE file? There is only one line:
> > exportMethods(formatMe)
> >
> > Here is Test's DESCRIPTION file:
> > Package: Test
> > Type: Package
> > Title: Testing format
> > Version: 1.0
> > Date: 2010-06-22
> > Author: Dan Murphy
> > Maintainer: Dan Murphy
> > Depends: methods
> > Description: Does format in a package work with S4 format method?
> > License: GPL (>= 2)
> > LazyLoad: yes
> >
> > (I would send the Help file, but I don't think that is the problem.)
> >
> > I am using version 2.11.1 on a Windows Vista machine.
> >
> > Any guidance would be appreciated. Thank you
> >
> > Dan Murphy
> >
> > [[alternative HTML version deleted]]
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
> --
> Martin Morgan
> Computational Biology / Fred Hutchinson Cancer Research Center
> 1100 Fairview Ave. N.
> PO Box 19024 Seattle, WA 98109
>
> Location: Arnold Building M1 B861
> Phone: (206) 667-2793
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] NAs and weighted.mean
R-developers, In version R 2.11.0, weighted.mean was changed such that: > weighted.mean(NA, na.rm=TRUE) [1] 0 rather than NaN as in previous versions of R. I see a note in the NEWS file indicates that weighted.mean was changed "so an infinite value with zero weight does not force an NaN result." In case the side effect of returning 0 rather than NaN in this case was unintentional, I'd like to propose that this case be reverted such that weighted.mean(NA, na.rm=TRUE) returns a NaN to be consistent with the mean function. Otherwise perhaps a note should be added in the documentation explaining this inconsistent behavior. I believe this patch should fix the problem while preserving the behavior in the NEWS file: -w <- w/sum(w) -sum((x*w)[w != 0]) +sum((x*w)[w != 0])/sum(w) Here's the full note from the NEWS file. o The default method of weighted.mean(x, w) coerces 'w' to be numeric (aka double); previously only integer weights were coerced. Zero weights are handled specially so an infinite value with zero weight does not force an NaN result. Thanks, Robert Robert McGehee, CFA Geode Capital Management, LLC One Post Office Square, 28th Floor | Boston, MA | 02109 Tel: 617/392-8396Fax:617/476-6389 mailto:robert.mcge...@geodecapital.com >This e-mail, and any attachments hereto, are intended for use by the addressee(s) only and may contain information that is (i) confidential information of Geode Capital Management, LLC and/or its affiliates, and/or (ii) proprietary information of Geode Capital Management, LLC and/or its affiliates. If you are not the intended recipient of this e-mail, or if you have otherwise received this e-mail in error, please immediately notify me by telephone (you may call collect), or by e-mail, and please permanently delete the original, any print outs and any copies of the foregoing. Any dissemination, distribution or copying of this e-mail is strictly prohibited. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
