Re: [Rd] R Citation through time
> On Tue, 12 Sep 2006 21:22:13 +0300 (EEST), > Ioannis Dimakos (ID) wrote: > Forgive me for being naive, > but I have not seen any reference where the ISBN was required. The apa > style that I use does not require the ISBN. It is not required for most citation *styles*. The main reason that we assigned an ISBN to R is that some people/journals/departments/... think that software cannot or should not be cited, and in that cases it often helps to have an ISBN, because it "looks more official". And the ISBN rules explicitly state that software should get an ISBN for full references. Best, Fritz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Error: package/namespace load failed for 'fortunes'
Hello!
I have the following R code in my .Rprofile file - just for fun.
library(fortunes)
fortune()
detach("package:fortunes")
This works nicely in R 2.3.1, but it throws the following error under
latest R-devel:
...
...
Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.
Error in rbind(rval, read.table(file, header = TRUE, sep = ";", quote =
"\"", :
could not find function "read.table"
Error: .onLoad failed in 'loadNamespace' for 'fortunes'
Error: package/namespace load failed for 'fortunes'
>
If I start R-devel with empty .Rprofile I am able to issue above R code
without problems. Is this caused by move of read.table() to utils package?
--
Lep pozdrav / With regards,
Gregor Gorjanc
--
University of Ljubljana PhD student
Biotechnical Faculty
Zootechnical Department URI: http://www.bfro.uni-lj.si/MR/ggorjan
Groblje 3 mail: gregor.gorjanc bfro.uni-lj.si
SI-1230 Domzale tel: +386 (0)1 72 17 861
Slovenia, Europefax: +386 (0)1 72 17 888
--
"One must learn by doing the thing; for though you think you know it,
you have no certainty until you try." Sophocles ~ 450 B.C.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] example(..., ask=getOption("example.ask"))
Hi,
I wish to return to the topic "[Rd] example(ask = .) - default ?"
discussed in R-devel on May 1, 2006, because I think it is related to
my problem.
In one of my Rd examples I generate multiple (20-30!) PNG files using
png()/dev.off(). I noticed that I get a "Hit to see next
plot:" for each png() call, when calling example() [interactively].
The code for example() has:
if (ask == "default")
ask <- echo && dev.interactive(orNone = TRUE)
if (ask) {
if (.Device != "null device") {
opar <- par(ask = TRUE)
on.exit(par(opar))
}
op <- options(par.ask.default = TRUE)
on.exit(options(op), add = TRUE)
}
When calling example() interactively, either with ask=TRUE (explicitly
or indirectly with getOption("example.ask") == "default"), option
'par.ask.default' is set to TRUE. This seems to be the reason for the
above. Example:
> options(par.ask.default=TRUE)
> png("foo.png"); plot(1); dev.off()
Hit to see next plot:
null device
1
> options(par.ask.default=FALSE)
> png("foo.png"); plot(1); dev.off()
null device
1
Best
Henrik
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] [Fwd: Byte size in human readable format]
Hello, I have looked once more into this issue and used options() approach with (yet another :() option - humanReadable. This is the behaviour in R-devel. > object.size(1000) [1] 32 > c(object.size(1000), object.size(1:1000), object.size(1:100)) [1] 324024 424 > options(humanReadable=TRUE) > object.size(1000) [1] 32 B > c(object.size(1000), object.size(1:1000), object.size(1:100)) [1] 32 B 4 kB 4 MB I am not very satisfied with the class approach I have taken as a lot of functions in R drop class attribute, say > sort(c(object.size(1:1000), object.size(1000)) ) [1] 32 4024 Is it possible to bypass this without writing special methods for "byte" class. I would appreciate any comments, suggestion. Thanks! Patches are available at: http://www.bfro.uni-lj.si/MR/ggorjan/tmp/object.size.R.patch http://www.bfro.uni-lj.si/MR/ggorjan/tmp/object.size.Rd.patch http://www.bfro.uni-lj.si/MR/ggorjan/tmp/NAMESPACE.patch http://www.bfro.uni-lj.si/MR/ggorjan/tmp/humanReadable.Rd Original Message Subject: Byte size in human readable format Date: Mon, 21 Aug 2006 14:14:52 +0200 From: Gregor Gorjanc <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] Organization: University of Ljubljana To: r-devel@r-project.org CC: Ales Korosec <[EMAIL PROTECTED]> Dear R-core, My friend and I have written a function to convert byte size into human readable format as can be done with -h argument in say ls, df or du shell commands. I have also tried to wrap it with print method with object.size. Is there any intereset to include such a function into say utils package? Any additional comments, suggestions are more than welcome. Function and its man page can be found at http://www.bfro.uni-lj.si/MR/ggorjan/tmp/object.size.R http://www.bfro.uni-lj.si/MR/ggorjan/tmp/humanReadable.Rd -- Lep pozdrav / With regards, Gregor Gorjanc -- University of Ljubljana PhD student Biotechnical Faculty Zootechnical Department URI: http://www.bfro.uni-lj.si/MR/ggorjan Groblje 3 mail: gregor.gorjanc bfro.uni-lj.si SI-1230 Domzale tel: +386 (0)1 72 17 861 Slovenia, Europefax: +386 (0)1 72 17 888 -- "One must learn by doing the thing; for though you think you know it, you have no certainty until you try." Sophocles ~ 450 B.C. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] example(..., ask=getOption("example.ask"))
And your point/question is?
par(ask = TRUE) applies to all devices, including png. Try setting
options(par.ask.default = FALSE in your example?
On Wed, 13 Sep 2006, Henrik Bengtsson wrote:
> Hi,
>
> I wish to return to the topic "[Rd] example(ask = .) - default ?"
> discussed in R-devel on May 1, 2006, because I think it is related to
> my problem.
>
> In one of my Rd examples I generate multiple (20-30!) PNG files using
> png()/dev.off(). I noticed that I get a "Hit to see next
> plot:" for each png() call, when calling example() [interactively].
>
> The code for example() has:
>
> if (ask == "default")
> ask <- echo && dev.interactive(orNone = TRUE)
> if (ask) {
> if (.Device != "null device") {
> opar <- par(ask = TRUE)
> on.exit(par(opar))
> }
> op <- options(par.ask.default = TRUE)
> on.exit(options(op), add = TRUE)
> }
>
> When calling example() interactively, either with ask=TRUE (explicitly
> or indirectly with getOption("example.ask") == "default"), option
> 'par.ask.default' is set to TRUE. This seems to be the reason for the
> above. Example:
>
> > options(par.ask.default=TRUE)
> > png("foo.png"); plot(1); dev.off()
> Hit to see next plot:
> null device
> 1
> > options(par.ask.default=FALSE)
> > png("foo.png"); plot(1); dev.off()
> null device
> 1
>
> Best
>
> Henrik
>
> __
> 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
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Error: package/namespace load failed for 'fortunes'
Gregor Gorjanc wrote:
> Hello!
>
> I have the following R code in my .Rprofile file - just for fun.
>
> library(fortunes)
> fortune()
> detach("package:fortunes")
>
> This works nicely in R 2.3.1, but it throws the following error under
> latest R-devel:
>
> ...
> ...
> Type 'demo()' for some demos, 'help()' for on-line help, or
> 'help.start()' for an HTML browser interface to help.
> Type 'q()' to quit R.
>
> Error in rbind(rval, read.table(file, header = TRUE, sep = ";", quote =
> "\"", :
> could not find function "read.table"
> Error: .onLoad failed in 'loadNamespace' for 'fortunes'
> Error: package/namespace load failed for 'fortunes'
>
> If I start R-devel with empty .Rprofile I am able to issue above R code
> without problems. Is this caused by move of read.table() to utils package?
Your intuition was right. Just add library(utils) before
library(fortunes), and it works. Your .Rprofile is executed before
.First.sys() (which loads default packages) in base package.
?Startup explains it all.
This raises an interesting topic for me:
In R-2.3.1, .First.sys() autloads() a few functions from the various
default packages (utils, stats, methods, graphics) IF those packages
weren't specified in the default packages option (or the environment
variable R_DEFAULT_PACKAGES). For instance, if a user doesn't want the
utils package automatically loaded, then .First.sys() does this:
sch <- search()
if(! "package:utils" %in% sch) {
autoload("example", "utils")
autoload("methods", "utils")
autoload("str", "utils")
}
which will automagically load utils if a call to example, methods, or
str is made (why just those three? why not others in utils). I presume
there was some heuristic to determine exactly which functions were
autoloaded.
Now in R-trunk today, I see that there are no autloaded functions set up
from .First.sys() for any of the default packages. So if R is started
with R_DEFAULT_PACKAGES=NULL, then no default packages will be loaded
and no functions will be set up via autoload(). Why?
Jeff
--
http://biostat.mc.vanderbilt.edu/JeffreyHorner
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] No more autload() calls in .First.sys() ?
Jeffrey Horner wrote:
[...]
> This raises an interesting topic for me:
>
> In R-2.3.1, .First.sys() autloads() a few functions from the various
> default packages (utils, stats, methods, graphics) IF those packages
> weren't specified in the default packages option (or the environment
> variable R_DEFAULT_PACKAGES). For instance, if a user doesn't want the
> utils package automatically loaded, then .First.sys() does this:
>
> sch <- search()
> if(! "package:utils" %in% sch) {
> autoload("example", "utils")
> autoload("methods", "utils")
> autoload("str", "utils")
> }
>
> which will automagically load utils if a call to example, methods, or
> str is made (why just those three? why not others in utils). I presume
> there was some heuristic to determine exactly which functions were
> autoloaded.
To answer this, all I had to do is look at the subversion log:
-
r27733 | ripley | 2003-12-21 04:21:33 -0600 (Sun, 21 Dec 2003) | 3 lines
allow all the standard examples to run with R_DEFAULT_PACKAGES=NULL
by judicious autoloading
-
That makes sense. But what about the change for R-trunk?
>
> Now in R-trunk today, I see that there are no autloaded functions set up
> from .First.sys() for any of the default packages. So if R is started
> with R_DEFAULT_PACKAGES=NULL, then no default packages will be loaded
> and no functions will be set up via autoload(). Why?
>
> Jeff
--
http://biostat.mc.vanderbilt.edu/JeffreyHorner
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] package.skeleton() in R-2.4.1
The issue here is the incomplete deparsing of S4 objects in pre-2.4.0.
I am really not sure you want to make a package this way: rather I would
want the setClass etc calls in the package code.
On Tue, 12 Sep 2006, Robin Hankin wrote:
> Hi
>
> R version 2.4.0 alpha (2006-09-06 r39158)
> MacOSX 10.4.7
>
>
> There was a thread some time ago as to whether the structure created by
> package.skeleton() would pass R CMD check.
>
> I have an example where package.skeleton() gives an R file that gives an
> error when sourced.
>
>
> If I type
>
> setClass("brob",
> representation = representation
> (x="numeric",positive="logical"),
> prototype = list(x=numeric(),positive=logical())
> )
>
> setGeneric("getX",function(x){standardGeneric("getX")})
> setMethod("getX","brob",function(x)[EMAIL PROTECTED])
>
>
> (which is legal, AFAICS), then
>
> package.skeleton(path="~")
>
> I get a file ~/anRpackage/R/getX.R containing:
>
>
> "getX" <-
> structure(function(x){standardGeneric("getX")}
> , generic = structure("getX", package = ".GlobalEnv"), package =
> ".GlobalEnv", group = list(), valueClass = character(0), signature =
> "x", default = object of class structure("MethodsList", package = "methods")>,
> skeleton = quote(function (x)
> stop("invalid call in method dispatch to 'getX' (no default method)",
> domain = NA)(x)), class = structure
> ("nonstandardGenericFunction", package = "methods"))
>
>
> [subject to line breaking] but this file gives an error when
> sourced (below). I didn't get this problem with R-2.3.1.
>
>
> > > source("/Users/rksh/anRpackage/R/getX.R")
> Error in parse(file, n = -1, NULL, "?") : syntax error at
> 2: structure(function(x){standardGeneric("getX")}
> 3: , generic = structure("getX", package = ".GlobalEnv"), package =
> ".GlobalEnv", group = list(), valueClass = character(0), signature =
> "x", default = <
> >
>
>
>
> Am I doing something wrong?
>
>
>
> --
> Robin Hankin
> Uncertainty Analyst
> National Oceanography Centre, Southampton
> European Way, Southampton SO14 3ZH, UK
> tel 023-8059-7743
>
> __
> 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
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Dringend, GESCHAEFTSVORSCHLAG. (PR#92 23)
Dringend, GESCHAEFTSVORSCHLAG.=0D=0A=0D=0AMein Name ist Jesen Bakker und = ich bin der Leiter des Corporate Affairs Committee in der South African R= eserve Bank in S=FCdafrika. Zur Zeit halte ich mich in den Niederlanden z= u einer Fortbildung auf. Ich kontaktiere Sie bez=FCglich des Transfers ei= ner sehr gro=DFen Summe Geldes vom Konto eines Verstorbenen. Ich wei=DF, = da=DF eine Transaktion dieser Gr=F6=DFenordnung zun=E4chst bei jedem Beso= rgnis erregen wird und ich versichere Ihnen, da=DF sich um alles gek=FCm= mert wird.Aufgrund der Dringlichkeit der Angelegenheit habe ich mich ents= chlossen, Sie zu kontaktieren.=0D=0A=0D=0AEs geht um folgendes:=0D=0A=0D=0A= Einer meiner Kollegen ist f=FCr das Konto von Gerald Uirich zust=E4ndig, = der im Oktober bei einem Flugzeugabsturz ums Leben kam. Er befand sich ge= meinsam mit anderen Passagieren an Bord einer Egyptian Airline 990. Seit = diesem Vorfall ist niemand seiner n=E4chsten Verwandten mehr am Leben, de= r als sein Erbe Anspr=FCche auf das Guthaben auf seinem Konto erheben k=F6= nnte. Wir k=F6nnen jedoch gem=E4=DF unserer Richtlinien das Geld nicht au= szahlen, bevor jemand als Angeh=F6riger und Erbe auftritt und seinen Ansp= ruch geltend macht. Aufgrund dieser Entdeckung und der =DCbereinstimmung = Ihres Namens mit dem des Verstorbenen bitten meine Kollegen und ich Sie n= un um Ihre Erlaubnis, sich als n=E4chsten Angeh=F6rigen des Verstorbenen = anzugeben. Die gesamte Abwicklung und Dokumentation wird sorgf=E4ltig von= mir durchgef=FChrt, damit das Guthaben von 20.5 Millionen US$ an Sie als= n=E4chsten Angeh=F6rigen ausgezahlt werden kann.=0D=0A=0D=0AAndernfalls = wird die gesamte Summe nach f=FCnf Jahren in das Eigentum der Bank =FCber= gehen und die Direktoren der Bank werden sie untereinander aufteilen. Auf= grund dieser Tatsache habe ich mich entschlossen, mich an Sie zu wenden, = damit Sie als Erbe auftreten k=F6nnen und nicht alles den Direktoren zugu= te kommt. Da aber die Person, die im Testament als Erbin genannt wird, mi= t ihm gemeinsam verstorben ist, haben wir vom Nachla=DFverwalter den Auft= rag bekommen, ein Familienmitglied des Verstorbenen ausfindig zu machen, = da=DF das Erbe antreten kann. Wir bitten Sie, unseren Vorschlag anzunehme= n und versichern Ihnen, da=DF alles absolut risikofrei f=FCr Sie ablaufen= wird.=0D=0A=0D=0AWir werden Sie mit 5 Millionen US$ an der Transaktion b= eteiligen, den restlichen Betrag werden meine Kollegen und ich f=FCr. Fal= ls Sie interessiert sind, schicken Sie mir bitte folgende Angaben:=0D=0A=0D= =0A1. Name/Firmen Name um die erforderlichen Dokumente vorzubereiten=0D=0A= 2. Pers=F6nliche Telefon- und Fax-Nummern =0D=0Azu meiner Privaten email = addresse: [EMAIL PROTECTED] mit Ihrer email addresse, damit ich die wei= teren relevanten Details in dieser Sache Ihnen mitteilen kann. F=FCr wei= tere Fragen k=F6nnen Sie mich unter 0031626320564 jeder Zeit erreichen. D= anke im voraus. Wir bitten sie eindringlich, die Angelegenheit vertraulic= h zu behandeln.=0D=0A=0D=0ABitte antworten Sie mir schnellstm=F6glich und= Gott segne sie.=0D=0A=0D=0AMit freundlichen grussen.=0D=0AJesen Bakker (= Dr)=0D=0ASouth African Reserve.=0D=0A=0A=0A- ALICE SE= CURITE ENFANTS -=0AProt=E9gez vos enfants des dangers= d'Internet en installant S=E9curit=E9 Enfants, le contr=F4le parental d'= Alice.=0Ahttp://www.aliceadsl.fr/securitepc/default_copa.asp=0A __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] S4 Method dispatch in recent 2.4.0alpha
Although there is not enough information to be sure, this may be
related to an issue uncovered in other testing, for which a patch has
just been committed.
The issue arises if the same generic function is defined in several
packages. For example, Matrix and msbase both have methods for the
plot() function in graphics. Since that function is not a generic,
creating methods causes a generic function to be saved in the two
packages' export environment.
So attaching both packages gives 3 versions of plot(), two generic and
one not.
> find("plot")
[1] "package:msbase" "package:Matrix" "package:graphics"
Note that this is NOT a question of having DIFFERENT generics with the
same name; both these generics have package slot equal to "graphics" and
therefore they refer to the same function.
The issue that arose was that, while a cached generic for plot() had all
the methods, the methods table in the individual packages generally did
not. So here, a call to plot() picks up the generic from msbase, which
may not have the methods defined in Matrix. The symptom is that plot(x)
from the global environment fails to find a method, say for "coef.lmer"
defined in Matrix, even though showMethods("plot") and
selectMethod("plot", "coef.lmer") show the method.
The version committed today copies the cached version of the generic
into the exported environment of the individual packages, so that all
methods are available regardless of the order of the packages in the
search list.
Again, remember that this is only when the package slot matches. The
following should work, although the sanity of the programmer is in doubt.
> plot <- function(theta) theta+1
> setGeneric("plot", package="myPackage",
function(theta)standardGeneric("plot"))
[1] "plot"
> showMethods("plot")
Function: plot (package myPackage)
theta="ANY"
The user now would have to disambiguate:
> Matrix::plot(1:10)
Hit to see next plot:
> plot(1:10)
[1] 2 3 4 5 6 7 8 9 10 11
The programmer should usually set up the imports for a package so that
there is no ambiguity about which version is meant. Also, with 2.4.x
one should be able to supply the generic _function_ rather than just its
name as the argument to setMethod(). But it's not claimed that
something like the above works completely as one would expect.
The caching mechanism only applies to globally visible generic
functions. At the moment, non-exported (and so private) versions of a
generic like plot are not cached. Primitives unfortunately are always
global.
There's some related discussion on the web page
http://developer.r-project.org/howMethodsWork.pdf
John
One more comment: For the future, I believe that the right attitude is
that there is one version of this generic function, and it lives in the
"graphics" package (yet one more time, _this_ generic function,
identified by its name and package slot). However, to implement that
view cleanly needs a couple of things we don't have:
1. a centralized dispatch for all generic functions, somewhat as is
done now for primitives.
2. methods labeled by the full reference to the classes--the class name
plus the package where the definition of the class exists. Otherwise,
we can't be completely general about method selection. Right now the
system does not allow the same generic to have _public_ methods for two
classes of the same name.
These changes are a bit too much for the few weeks left for 2.4.0.
Oosting, J. (PATH) wrote:
> Your suggestions worked ok in the example, but in my case there is yet
> another package that implements a plot method.
> Now the plotting from within the package works, but plotting from outside the
> package, on the console, gives an error as if plot.default is invoked.
>
>> class(myplot)
>>
> [1] "gt.barplot"
> attr(,"package")
> [1] "globaltest"
>
>> plot(myplot)
>>
> Error in xy.coords(x, y, xlabel, ylabel, log) :
> 'x' and 'y' lengths differ
>
>
> Rgraphviz implements a plot method on 2 classes: graph and Ragraph
> multtest implements a plot method on 1 class: MTP
>
> globaltest, the package i'm working on, depends on multtest, and suggests
> Rgraphviz. Class gt.barplot implements a plot method
>
>
> the output of showMethods("plot")
>
>> showMethods("plot")
>>
> Function: plot, (package graphics)
> x="ANY"
> x="graph"
> x="gt.barplot"
> x="MTP"
> x="Ragraph"
>
> Rgraphviz has a proper NAMESPACE and I created one for multtest that imports
> plot from graphics, and exports plot as a method, because they are not
> dependent on each other that does seem ok.
> In globaltest I import the plot method from multtest.
>
> How to deal with this.
>
>
>> sessionInfo()
>>
> R version 2.4.0 alpha (2006-09-11 r39258)
> i386-pc-mingw32
>
> locale:
> LC_COLLATE=Dutch_Netherlands.1252;LC_CTYPE=Dutch_Netherlands.1252;LC_MONETARY=Dutch_Netherlands.1252;LC_NUMERIC=C;LC_TIME=Dutch_Netherlands.1252
>
> attached base packages:
>
Re: [Rd] S4 Method dispatch in recent 2.4.0alpha
I have tried it on the patched version of R, and it works now.
Thanks,
Jan
Van: John Chambers [mailto:[EMAIL PROTECTED]
Although there is not enough information to be sure, this may be related to an
issue uncovered in other testing, for which a patch has just been committed.
The issue arises if the same generic function is defined in several packages.
For example, Matrix and msbase both have methods for the plot() function in
graphics. Since that function is not a generic, creating methods causes a
generic function to be saved in the two packages' export environment.
So attaching both packages gives 3 versions of plot(), two generic and one not.
> find("plot")
[1] "package:msbase" "package:Matrix" "package:graphics"
Note that this is NOT a question of having DIFFERENT generics with the same
name; both these generics have package slot equal to "graphics" and therefore
they refer to the same function.
The issue that arose was that, while a cached generic for plot() had all the
methods, the methods table in the individual packages generally did not. So
here, a call to plot() picks up the generic from msbase, which may not have the
methods defined in Matrix. The symptom is that plot(x) from the global
environment fails to find a method, say for "coef.lmer" defined in Matrix, even
though showMethods("plot") and selectMethod("plot", "coef.lmer") show the
method.
The version committed today copies the cached version of the generic into the
exported environment of the individual packages, so that all methods are
available regardless of the order of the packages in the search list.
Again, remember that this is only when the package slot matches. The following
should work, although the sanity of the programmer is in doubt.
> plot <- function(theta) theta+1
> setGeneric("plot", package="myPackage",
> function(theta)standardGeneric("plot"))
[1] "plot"
> showMethods("plot")
Function: plot (package myPackage)
theta="ANY"
The user now would have to disambiguate:
> Matrix::plot(1:10)
Hit to see next plot:
> plot(1:10)
[1] 2 3 4 5 6 7 8 9 10 11
The programmer should usually set up the imports for a package so that there is
no ambiguity about which version is meant. Also, with 2.4.x one should be able
to supply the generic _function_ rather than just its name as the argument to
setMethod(). But it's not claimed that something like the above works
completely as one would expect.
The caching mechanism only applies to globally visible generic functions. At
the moment, non-exported (and so private) versions of a generic like plot are
not cached. Primitives unfortunately are always global.
There's some related discussion on the web page
http://developer.r-project.org/howMethodsWork.pdf
John
One more comment: For the future, I believe that the right attitude is that
there is one version of this generic function, and it lives in the "graphics"
package (yet one more time, _this_ generic function, identified by its name and
package slot). However, to implement that view cleanly needs a couple of
things we don't have:
1. a centralized dispatch for all generic functions, somewhat as is done now
for primitives.
2. methods labeled by the full reference to the classes--the class name plus
the package where the definition of the class exists. Otherwise, we can't be
completely general about method selection. Right now the system does not allow
the same generic to have _public_ methods for two classes of the same name.
These changes are a bit too much for the few weeks left for 2.4.0.
Oosting, J. (PATH) wrote:
Your suggestions worked ok in the example, but in my case there is yet
another package that implements a plot method.
Now the plotting from within the package works, but plotting from
outside the package, on the console, gives an error as if plot.default is
invoked.
class(myplot)
[1] "gt.barplot"
attr(,"package")
[1] "globaltest"
plot(myplot)
Error in xy.coords(x, y, xlabel, ylabel, log) :
'x' and 'y' lengths differ
Rgraphviz implements a plot method on 2 classes: graph and Ragraph
multtest implements a plot method on 1 class: MTP
globaltest, the package i'm working on, depends on multtest, and
suggests Rgraphviz. Class gt.barplot implements a plot method
the output of showMethods("plot")
showMethods("plot")
Function: plot, (package graphics)
x="ANY"
x="graph"
x="gt.barplot"
x="MTP"
x="Ragraph"
Rgraphviz has a proper NAMESPACE and I created one for multtest that
imports plot from graphics, and exports plot as a method, because they are not
dependent on e
[Rd] demo names with spaces?
Does R support demo names with spaces? I tried placing a file like "My Demo Name.R" in the demo subdirectory, and placing a line that begins with "My Demo Name" in 00Index, but R CMD check does not like this. It reads the line in 00Index as "My, and it doesn't think there is a 00Index entry for "My Demo Name". I have no problem going back to MyDemoName.R, but I'm curious to know if there is support for names containing spaces. Thanks, ds __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] demo names with spaces?
There are two issues here: 1) file names with spaces are not supported, and indeed you cannot install such a package on Windows. Because make is used, this is pretty fundamental. 2) The parsing code for 00Index used by 'check' assumes whitespace separates the name and the title. In index files generated by R the separator is a tab, but demo indices are hand-crafted. You can use underlines in the file and demo names. On Wed, 13 Sep 2006, Dominick Samperi wrote: > Does R support demo names with spaces? > > I tried placing a file like "My Demo Name.R" in > the demo subdirectory, and placing a line that > begins with "My Demo Name" in 00Index, but > R CMD check does not like this. It reads the > line in 00Index as "My, and it doesn't think there > is a 00Index entry for "My Demo Name". > > I have no problem going back to MyDemoName.R, > but I'm curious to know if there is support for > names containing spaces. -- 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 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R-devel: rownames of a data.frame
Hello! Data.frames have new rownames funcionality, however in use of colnames<- in R-devel "changes" this. Here is the example: > df1 <- data.frame(letters[1:5]) > attributes(df1) $names [1] "letters.1.5." $row.names [1] 1 2 3 4 5 $class [1] "data.frame" > colnames(df1) <- "bla" > attributes(df1) $names [1] "bla" $row.names [1] "1" "2" "3" "4" "5" $class [1] "data.frame" ?rownames/colnames help page (R-devel) says that value is coerced to character, but why are rownames coerced to character if I assign colnames to a data.frame? -- Lep pozdrav / With regards, Gregor Gorjanc -- University of Ljubljana PhD student Biotechnical Faculty Zootechnical Department URI: http://www.bfro.uni-lj.si/MR/ggorjan Groblje 3 mail: gregor.gorjanc bfro.uni-lj.si SI-1230 Domzale tel: +386 (0)1 72 17 861 Slovenia, Europefax: +386 (0)1 72 17 888 -- "One must learn by doing the thing; for though you think you know it, you have no certainty until you try." Sophocles ~ 450 B.C. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] attributes of S4 objects
I am having a bit of a struggle deciding when to use attributes with
S4 objects. Clearly the 'class' attribute will always be present.
But it is not clear to me whether the architects of the methods
package intend that other attributes, such as 'names', will still be
used when the S4 implementation is complete.
I notice that, when you create a formal object from an informal one
with attributes, the attributes are (often) assigned to the formal
object. For example,
setClass("Numeric", representation("numeric"))
vec <- 1:10
names(vec) <- letters[1:10]
comment(vec) <- "comment"
Vec <- new("Numeric", vec)
attributes(Vec) ## 'names' and 'comment' attributes are assigned to
the formal object
But I also notice that, in the absence of an appropriate 'coerce'
method, 'as( , superclass)' will return an object without attributes
as(Vec, "numeric") ## gives an unnamed vector of mode numeric with no
comment attribute
Because of this, I have found myself writing methods for the sole
purpose of preserving attributes when coercing between basic data
types and formal classes that extend them. But the default methods
for coercing to the basic data types clearly want attributes to be
stripped (they do so explicitly when strict=TRUE (the default)). I
am thinking that maybe it was always intended that non-class
attributes would not be used with formal objects, and that instead
analogous slots would appear in any formal objects that extend basic
data types (like the Dim and Dimnames attributes in the 'Matrix'
mother class from the Matrix package).
Is that true? Are attributes un-S4? Any and all style advice or
examples would be appreciated.
Franklin Parlamis
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
