Re: [Rd] S4 setClass / initialize misunderstanding
On 02/02/2010 02:12 PM, bull...@stat.berkeley.edu wrote:
>
> Hi, I recently ran into this problem. I couldn't find any mention of it in
> the setClass documentation.
>
> setClass("Foo", representation(file = "character"))
> setMethod("initialize", "Foo", function(.Object, file) {
> print(file)
> })
> setClass("Bar", contains = "Foo")
>
> And the error:
>
> Error in print(file) : argument "file" is missing, with no default
>
> The workaround is to interchange the setMethod and the second setClass
> call, however, it begs the question why is setClass calling an initialize
> method? As always, if I have missed documentation concerning this please
> point me there.
Hi Jim -- The hint is in traceback()
> setClass("Bar", contains="Foo")
Error in print(file) : argument "file" is missing, with no default
> traceback()
[snip]
5: new(toDef)
4: .simpleCoerceExpr(Class, to, names(slots), classDef2)
3: makeExtends(name, what, slots = slots, classDef2 = whatClassDef,
package = package)
2: makeClassRepresentation(Class, properties, superClasses, prototype,
package, validity, access, version, sealed, where = where)
1: setClass("Bar", contains = "Foo")
the source
if(!isVirtualClass(toDef))
toClass <- class(new(toDef)) # get it with the package slot correct
subversion
% svn annotate src/library/methods/R/RClassUtils.R
48221jmc if(!isVirtualClass(toDef))
48221jmc toClass <- class(new(toDef)) # get it with
% svn log -r 48221
r48221 | jmc | 2009-03-26 14:28:03 -0700 (Thu, 26 Mar 2009) | 1 line
fix bug in defining as() methods--got wrong package for simple contains
class with no added slots
and the mailing list
https://stat.ethz.ch/pipermail/r-devel/2009-March/052829.html
but the bottom line is that you want
validObject(new("Foo"))
to return TRUE. I'd write (if an initialize method is really required --
what happens if there's a constructor Foo() that constructs the
arguments to new("Foo", <...>) correctlyl?)
setMethod(initialize, function(.Object, ..., file=character(0)) {
## process file, then
callNextMethod(.Object, ..., file=file)
})
'file' gets a default argument. '...' allows derived classes to
callNextMethod (explicitly, or implicitly by a call to new("Bar",
<...>)) and get the expected 'initialize' behavior. Placing 'file' after
'...' means that 'file' doesn't capture unnamed arguments, which are
supposed to be prototypes for classes that .Object extends.
Martin
>
> Thanks, jim
>
> __
> 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] codoc mismatches warning
On Tue, 2 Feb 2010 23:05:35 +0100, Kurt Hornik wrote: >> Sebastian P Luque writes: >> Hi, Doing 'R CMD check diveMove' is now throwing this message: > Which version of diveMove is this? It's a development version (0.9.7) at R-Forge. The one showing this warning hasn't been built yet by the automated system at R-Forge, but can be downloaded from there. -- Seb __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] S4 setClass / initialize misunderstanding
Hi, I recently ran into this problem. I couldn't find any mention of it in
the setClass documentation.
setClass("Foo", representation(file = "character"))
setMethod("initialize", "Foo", function(.Object, file) {
print(file)
})
setClass("Bar", contains = "Foo")
And the error:
Error in print(file) : argument "file" is missing, with no default
The workaround is to interchange the setMethod and the second setClass
call, however, it begs the question why is setClass calling an initialize
method? As always, if I have missed documentation concerning this please
point me there.
Thanks, jim
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] codoc mismatches warning
> Sebastian P Luque writes:
> Hi,
> Doing 'R CMD check diveMove' is now throwing this message:
Which version of diveMove is this?
-k
> Data codoc mismatches from documentation object 'sealLocs':
> Variables in data frame 'sealLocs'
> Code: id.time.class.lon.lat
> Docs: class id lat lon time
> with:
R> sessionInfo()
> R version 2.10.1 (2009-12-14)
> x86_64-pc-linux-gnu
> locale:
> [1] LC_CTYPE=en_CA.UTF-8 LC_NUMERIC=C
> LC_TIME=en_CA.UTF-8LC_COLLATE=en_CA.UTF-8
> [5] LC_MONETARY=C LC_MESSAGES=en_CA.UTF-8
> LC_PAPER=en_CA.UTF-8 LC_NAME=C
> [9] LC_ADDRESS=C LC_TELEPHONE=C
> LC_MEASUREMENT=en_CA.UTF-8 LC_IDENTIFICATION=C
> attached base packages:
> [1] stats graphics grDevices utils datasets methods base
> other attached packages:
> [1] slmisc_0.7.3 lattice_0.18-3
> loaded via a namespace (and not attached):
> [1] grid_2.10.1
> I've never had this problem in previous versions. 'sealLocs' is a *.csv
> file with this head:
> ,-[ head -n5 data/sealLocs.csv ]
> | "id","time","class","lon","lat"
> | "ringy",2006-06-14 20:31:46,"2",-72.655,40.915
> | "ringy",2006-06-15 05:58:14,"3",-72.656,40.918
> | "ringy",2006-06-15 07:56:32,"3",-72.657,40.919
> | "ringy",2006-06-15 19:07:49,"2",-72.474,40.834
> `-
> and this is the relevant section of man/sealLocs.Rd:
> \format{A data frame with the following information:
> \describe{
> \item{id}{String naming the seal the data come from.}
> \item{time}{The date and time of the location.}
> \item{class}{The ARGOS location quality classification.}
> \item{lon, lat}{x and y geographic coordinates of each location.}
> }
> }
> Any pointers to avoid the warning? Thanks.
> Cheers,
> --
> Seb
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] codoc mismatches warning
Hi,
Doing 'R CMD check diveMove' is now throwing this message:
Data codoc mismatches from documentation object 'sealLocs':
Variables in data frame 'sealLocs'
Code: id.time.class.lon.lat
Docs: class id lat lon time
with:
R> sessionInfo()
R version 2.10.1 (2009-12-14)
x86_64-pc-linux-gnu
locale:
[1] LC_CTYPE=en_CA.UTF-8 LC_NUMERIC=C LC_TIME=en_CA.UTF-8
LC_COLLATE=en_CA.UTF-8
[5] LC_MONETARY=C LC_MESSAGES=en_CA.UTF-8LC_PAPER=en_CA.UTF-8
LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
LC_MEASUREMENT=en_CA.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] slmisc_0.7.3 lattice_0.18-3
loaded via a namespace (and not attached):
[1] grid_2.10.1
I've never had this problem in previous versions. 'sealLocs' is a *.csv
file with this head:
,-[ head -n5 data/sealLocs.csv ]
| "id","time","class","lon","lat"
| "ringy",2006-06-14 20:31:46,"2",-72.655,40.915
| "ringy",2006-06-15 05:58:14,"3",-72.656,40.918
| "ringy",2006-06-15 07:56:32,"3",-72.657,40.919
| "ringy",2006-06-15 19:07:49,"2",-72.474,40.834
`-
and this is the relevant section of man/sealLocs.Rd:
\format{A data frame with the following information:
\describe{
\item{id}{String naming the seal the data come from.}
\item{time}{The date and time of the location.}
\item{class}{The ARGOS location quality classification.}
\item{lon, lat}{x and y geographic coordinates of each location.}
}
}
Any pointers to avoid the warning? Thanks.
Cheers,
--
Seb
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Missing arg default values in Docs are not triggering an 'R CMD check' warning
Hi,
Having
foo <- function(x, y, z) {TRUE}
in my code and
foo(x, y=NULL, z=0)
in the \usage section of my man page will trigger the
following warning during R CMD check:
* checking for code/documentation mismatches ... WARNING
Codoc mismatches from documentation object 'foo':
foo
Code: function(x, y, z)
Docs: function(x, y = NULL, z = 0)
Mismatches in argument default values:
Name: 'y' Code: Docs: NULL
Name: 'z' Code: Docs: 0
which is good.
But if the mismatch is the other way around i.e if the argument
default values are specified in Code and not in Docs, then
R CMD check won't say anything. Is that intended or is it a bug?
Thanks,
H.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] [lbrag...@gmail.com: [wishlist] \href in Rd] (PR#14204)
mmm maybe lost somewhere cheers - Forwarded message from Luca Braglia - Subject: [wishlist] \href in Rd Date: Wed, 27 Jan 2010 16:40:54 +0100 From: Luca Braglia To: R Bug User-Agent: Mutt/1.5.20 (2009-06-14) Following this thread https://stat.ethz.ch/pipermail/r-help/2010-January/225856.html it would be nice having an implementation of the LaTeX \href for Rd too. Thanks in advance Luca - End forwarded message - __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] [lbrag...@gmail.com: [wishlist] \href in Rd]
mmm maybe lost somewhere cheers - Forwarded message from Luca Braglia - Subject: [wishlist] \href in Rd Date: Wed, 27 Jan 2010 16:40:54 +0100 From: Luca Braglia To: R Bug User-Agent: Mutt/1.5.20 (2009-06-14) Following this thread https://stat.ethz.ch/pipermail/r-help/2010-January/225856.html it would be nice having an implementation of the LaTeX \href for Rd too. Thanks in advance Luca - End forwarded message - __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] Suppressing scientific notation on plot axis tick labels (PR#14203)
murd...@stats.uwo.ca wrote:
> On 02/02/2010 6:20 AM, Dimitri Shvorob wrote:
>> Ruben Roa has kindly suggested using 'scipen' option - cf.
>>
>>> fixed notation will be preferred unless it is more than =C3=A2=E2=82=AC=
=CB=9Cscipen=C3=A2=E2=82=AC=E2=84=A2 digits
>>> wider.
>> However,=20
>>
>> options(scipen =3D 50)
>> x =3D c(1e7, 2e7)
>> barplot(x)=20
>>
>> still does not produce the desired result.
>=20
> This is strange. I see what you describe the first time through, but
> if I print the option I get the non-scientific labels on the second plo=
t:
>=20
> options(scipen =3D 50)
> x =3D c(1e7, 2e7)
> barplot(x)
> options("scipen")
> barplot(x)
>=20
> Looks like some sort of caching bug to me. I don't think I'll have tim=
e=20
> to track this down; this is a crazy week. I see the same thing in=20
> R-devel as in 2.10.1.
Same thing with, e.g.
x <- c(1e7, 2e7)
options(scipen =3D3)
barplot(x)
x
barplot(x)
options(scipen=3D0)
barplot(x)
x
barplot(x)
> Duncan Murdoch
>=20
> Version:
> platform =3D i386-pc-mingw32
> arch =3D i386
> os =3D mingw32
> system =3D i386, mingw32
> status =3D
> major =3D 2
> minor =3D 10.1
> year =3D 2009
> month =3D 12
> day =3D 14
> svn rev =3D 50720
> language =3D R
> version.string =3D R version 2.10.1 (2009-12-14)
>=20
> Windows XP (build 2600) Service Pack 3
>=20
> Locale:
> LC_COLLATE=3DEnglish_Canada.1252;LC_CTYPE=3DEnglish_Canada.1252;LC_MONE=
TARY=3DEnglish_Canada.1252;LC_NUMERIC=3DC;LC_TIME=3DEnglish_Canada.1252
>=20
> Search Path:
> .GlobalEnv, package:stats, package:graphics, package:grDevices,=20
> package:utils, package:datasets, package:methods, Autoloads, package:ba=
se
>=20
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--=20
O__ Peter Dalgaard =C3=98ster Farimagsgade 5, Entr.B=
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~ - (p.dalga...@biostat.ku.dk) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] Suppressing scientific notation on plot axis tick labels (PR#14202)
murd...@stats.uwo.ca wrote:
> On 02/02/2010 6:20 AM, Dimitri Shvorob wrote:
>> Ruben Roa has kindly suggested using 'scipen' option - cf.
>>
>>> fixed notation will be preferred unless it is more than ‘scipen’ digits
>>> wider.
>> However,
>>
>> options(scipen = 50)
>> x = c(1e7, 2e7)
>> barplot(x)
>>
>> still does not produce the desired result.
>
> This is strange. I see what you describe the first time through, but
> if I print the option I get the non-scientific labels on the second plot:
>
> options(scipen = 50)
> x = c(1e7, 2e7)
> barplot(x)
> options("scipen")
> barplot(x)
>
> Looks like some sort of caching bug to me. I don't think I'll have time
> to track this down; this is a crazy week. I see the same thing in
> R-devel as in 2.10.1.
Same thing with, e.g.
x <- c(1e7, 2e7)
options(scipen =3)
barplot(x)
x
barplot(x)
options(scipen=0)
barplot(x)
x
barplot(x)
> Duncan Murdoch
>
> Version:
> platform = i386-pc-mingw32
> arch = i386
> os = mingw32
> system = i386, mingw32
> status =
> major = 2
> minor = 10.1
> year = 2009
> month = 12
> day = 14
> svn rev = 50720
> language = R
> version.string = R version 2.10.1 (2009-12-14)
>
> Windows XP (build 2600) Service Pack 3
>
> Locale:
> LC_COLLATE=English_Canada.1252;LC_CTYPE=English_Canada.1252;LC_MONETARY=English_Canada.1252;LC_NUMERIC=C;LC_TIME=English_Canada.1252
>
> Search Path:
> .GlobalEnv, package:stats, package:graphics, package:grDevices,
> package:utils, package:datasets, package:methods, Autoloads, package:base
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~ - (p.dalga...@biostat.ku.dk) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] choose(n,k) when n is almost integer
I would like to add some more information concerning the patch C
to the function choose() proposed in the email
https://stat.ethz.ch/pipermail/r-devel/2009-December/056177.html
The patch uses transformations of choose(n, k), which are described in
http://www.cs.cas.cz/~savicky/R-devel/formulas_choose.pdf
The accuracy of the modified function choose(n, k) may be verified
on randomly generated examples using Rmpfr package
http://cran.at.r-project.org/web/packages/Rmpfr/index.html
and the script
http://www.cs.cas.cz/~savicky/R-devel/test_choose_2.R
The output, which i obtained, is
> source("test_choose_2.R")
k <= 9 max rel err = 9.41734e-16
k <= 19 max rel err = 2.084412e-15
k <= 29 max rel err = 3.170754e-15
k <= 39 max rel err = 4.99284e-14
k <= 49 max rel err = 5.927749e-14
k <= 59 max rel err = 6.526895e-14
k <= 69 max rel err = 6.526895e-14
k <= 79 max rel err = 8.783232e-14
k <= 89 max rel err = 1.051950e-13
k <= 99 max rel err = 1.051950e-13
k <= 109 max rel err = 1.072878e-13
k <= 119 max rel err = 1.072878e-13
k <= 129 max rel err = 1.179829e-13
k <= 139 max rel err = 1.247080e-13
k <= 149 max rel err = 1.247080e-13
k <= 159 max rel err = 1.255064e-13
k <= 169 max rel err = 1.255064e-13
k <= 179 max rel err = 1.267402e-13
k <= 189 max rel err = 1.311689e-13
k <= 199 max rel err = 1.573155e-13
k <= 209 max rel err = 1.844756e-13
Patch C also passes make check-all in the current development
version 2.11.0 (2010-02-01).
I appreciate comments.
Petr Savicky.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] Suppressing scientific notation on plot axis tick labels (PR#14202)
On 02/02/2010 6:20 AM, Dimitri Shvorob wrote:
> Ruben Roa has kindly suggested using 'scipen' option - cf.
>
>> fixed notation will be preferred unless it is more than âscipenâ digits
>> wider.
>
> However,
>
> options(scipen = 50)
> x = c(1e7, 2e7)
> barplot(x)
>
> still does not produce the desired result.
This is strange. I see what you describe the first time through, but
if I print the option I get the non-scientific labels on the second plot:
options(scipen = 50)
x = c(1e7, 2e7)
barplot(x)
options("scipen")
barplot(x)
Looks like some sort of caching bug to me. I don't think I'll have time
to track this down; this is a crazy week. I see the same thing in
R-devel as in 2.10.1.
Duncan Murdoch
Version:
platform = i386-pc-mingw32
arch = i386
os = mingw32
system = i386, mingw32
status =
major = 2
minor = 10.1
year = 2009
month = 12
day = 14
svn rev = 50720
language = R
version.string = R version 2.10.1 (2009-12-14)
Windows XP (build 2600) Service Pack 3
Locale:
LC_COLLATE=English_Canada.1252;LC_CTYPE=English_Canada.1252;LC_MONETARY=English_Canada.1252;LC_NUMERIC=C;LC_TIME=English_Canada.1252
Search Path:
.GlobalEnv, package:stats, package:graphics, package:grDevices,
package:utils, package:datasets, package:methods, Autoloads, package:base
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] str() and signs in imaginary parts (PR#14201)
My unix mailer might not work, so I send the report here: The function "str" perpetuates the sign of the imaginary part of the first array element which it should not: > str(c(1+2i,1-3i)); str(c(2-4i,11+3i)); cplx [1:2] 1+2i 1+3i# note the faulty 1 + 3i cplx [1:2] 2-4i 1-3i# note the faulty 1 - 3i > bug.report() Have a look at > (xx <- complex(real=rnorm(5,0,1),imag=rnorm(5,0,1))) [1] -0.686846-0.010655i 1.017494-0.644474i 0.212905-0.720527i [4] -0.843110+1.538344i -1.341294-0.741398i > str(xx,vec.len = 6) cplx [1:5] -0.687-0.011i 1.017-0.644i 0.213-0.721i -0.843-1.538i ... > --please do not edit the information below-- Version: platform = x86_64-apple-darwin9.8.0 arch = x86_64 os = darwin9.8.0 system = x86_64, darwin9.8.0 status = major = 2 minor = 10.1 year = 2009 month = 12 day = 14 svn rev = 50720 language = R version.string = R version 2.10.1 (2009-12-14) Locale: C Search Path: .GlobalEnv, package:tools, package:tcltk, package:survival, package:stats4, package:splines, package:spatial, package:rpart, package:nnet, package:nlme, package:mgcv, package:grid, package:foreign, package:datasets, package:codetools, package:cluster, package:class, package:boot, package:Matrix, package:MASS, package:graphics, package:grDevices, package:KernSmooth, package:stats, package:cwhmisc, package:lattice, package:utils, package:methods, Autoloads, package:base -- Christian W. Hoffmann, Rigiblickstrasse 15 b, CH-8915Hausen am Albis, Switzerland, Tel +41-44-7640853, c-w.hoffm...@sunrise.ch www.wsl.ch/personal_homepages/hoffmann/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
