[Rd] Trig.Rd typo (PR#9269)
Full_Name: Robin Hankin
Version: 2.4.0 RC
OS: MacOSX 10.4.7
Submission from: (NULL) (139.166.242.29)
The first cut line described in Trig.Rd for asin() is incorrect in the ascii
version of the manpage.
The Rd file reads:
For \code{asin()} and \code{acos()}, there are two cuts, both along
the real axis: \eqn{\left(-\infty, -1\right]}{\(-Inf, 1\]} and
Note the inconsistency between the ascii and latex equations.
It should read:
For \code{asin()} and \code{acos()}, there are two cuts, both along
the real axis: \eqn{\left(-\infty, -1\right]}{\(-Inf, -1\]} and
where the final "1" has been changed to a "-1". Ref: AMS-55, page 79,
figure 4.4.
It's very difficult to catch this kind of error: thanks to Kjetil Halvorson for
his sharp-eyed comment.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] pdf() and postscript() fails (PR#9268)
[EMAIL PROTECTED] wrote: > Full_Name: yury bakshi > Version: R-2.3.1 > OS: XP, cygwin Is this a self compiled version? The cygwin platform is not supported. > Submission from: (NULL) (24.187.26.0) > > > >> pdf() Works for me. > Error in pdf() : failed to load default encoding > In addition: Warning message: > failed to load encoding file 'WinAnsi.enc' Have you removed some files from your installation? Uwe Ligges >> postscript() > Error in postscript() : failed to load encoding > In addition: Warning message: > failed to load encoding file 'WinAnsi.enc' > > __ > 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] Trig.Rd typo (PR#9269)
Thank you, Robin (and Kjetil),
for spotting and reporting this so precisely.
This is a (somewhat rare) example of a bug that is trivial
enough to fix so the fix even made it into the "deep frozen"
release candidate (R 2.4.0, to be released tomorrow).
Martin Maechler, ETH Zurich
> "Robin" == r hankin <[EMAIL PROTECTED]>
> on Mon, 2 Oct 2006 09:51:39 +0200 (CEST) writes:
Robin> Full_Name: Robin Hankin Version: 2.4.0 RC OS: MacOSX
Robin> 10.4.7 Submission from: (NULL) (139.166.242.29)
Robin> The first cut line described in Trig.Rd for asin() is
Robin> incorrect in the ascii version of the manpage.
Robin> The Rd file reads:
Robin> For \code{asin()} and \code{acos()}, there are two
Robin> cuts, both along the real axis: \eqn{\left(-\infty,
Robin> -1\right]}{\(-Inf, 1\]} and
Robin> Note the inconsistency between the ascii and latex
Robin> equations. It should read:
Robin> For \code{asin()} and \code{acos()}, there are two
Robin> cuts, both along the real axis: \eqn{\left(-\infty,
Robin> -1\right]}{\(-Inf, -1\]} and
Robin> where the final "1" has been changed to a "-1". Ref:
Robin> AMS-55, page 79, figure 4.4.
Robin> It's very difficult to catch this kind of error:
Robin> thanks to Kjetil Halvorson for his sharp-eyed
Robin> comment.
Robin> __
Robin> R-devel@r-project.org mailing list
Robin> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] CCF and ACF
Dear all, given two numeric vectors x and y, the ACF(x) at lag k is cor(x(t),x(t+k)) while the CCF(x,y) at lag k is cor(x(t),y(t-k)). See below for a simple example. > set.seed(1) > x <- rnorm(10) > y <- rnorm(10) > x [1] -0.6264538 0.1836433 -0.8356286 1.5952808 0.3295078 -0.8204684 0.4874291 0.7383247 0.5757814 -0.3053884 > y [1] 1.51178117 0.38984324 -0.62124058 -2.21469989 1.12493092 -0.04493361 -0.01619026 0.94383621 0.82122120 0.59390132 > x <- x - mean(x); > y <- y -mean(y); ## ACF OF x(t) > print(acf(x,lag=2,plot=F),digits=5)) Autocorrelations of series 'x', by lag 012 1.0 -0.26486 -0.25352 ## For Instance ACF(x) at lag 1 is Corr(x(t),x(t+1)): > sum(x[1:9]*x[2:10])/sum(x^2) [1] -0.2648633 ## whereas CCF(x,y) at lag 1 is Corr(x(t),y(t-1)) > ccf(x,y,lag=2,plot=F) Autocorrelations of series 'X', by lag -2 -1 0 1 2 -0.139 0.593 -0.377 -0.382 0.116 > sum(x[1:9]*y[2:10])/sqrt(sum(x^2)*sum(y^2)) [1] 0.5930216 > sum(x[2:10]*y[1:9])/sqrt(sum(x^2)*sum(y^2)) [1] -0.3822885 from a quick survey on textbooks (Brockwell and Davis, Chatfield, Fuller) it looks like different authors use different conventions so that I think that it would be nice to clarify this in the documentation. Ciao Simone > R.version _ platform i386-pc-mingw32 arch i386 os mingw32 system i386, mingw32 status beta major 2 minor 4.0 year 2006 month 09 day20 svn rev39421 language R version.string R version 2.4.0 beta (2006-09-20 r39421) > Sys.getlocale() [1] "LC_COLLATE=English_United States.1252;LC_CTYPE=English_United States.1252;LC_MONETARY=English_United States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252" __ Simone Giannerini Dipartimento di Scienze Statistiche "Paolo Fortunati" Universita' di Bologna Via delle belle arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax: +39 051 232153 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] CCF and ACF
Using "ts" objects these can be written in the following consistent manner: > sum(ts(x) * lag(ts(x)) / sum(ts(x)^2)) [1] -0.2648633 > sum(ts(x) * lag(ts(y)) / sqrt(sum(ts(y)^2) * sum(ts(x)^2))) [1] 0.5930216 On 10/2/06, Simone Giannerini <[EMAIL PROTECTED]> wrote: > Dear all, > > given two numeric vectors x and y, the ACF(x) at lag k is > cor(x(t),x(t+k)) while the CCF(x,y) at lag k is cor(x(t),y(t-k)). See > below for a simple example. > > > set.seed(1) > > x <- rnorm(10) > > y <- rnorm(10) > > x > [1] -0.6264538 0.1836433 -0.8356286 1.5952808 0.3295078 -0.8204684 > 0.4874291 0.7383247 0.5757814 -0.3053884 > > y > [1] 1.51178117 0.38984324 -0.62124058 -2.21469989 1.12493092 > -0.04493361 -0.01619026 0.94383621 0.82122120 0.59390132 > > x <- x - mean(x); > > y <- y -mean(y); > > ## ACF OF x(t) > > print(acf(x,lag=2,plot=F),digits=5)) > > Autocorrelations of series 'x', by lag > >012 > 1.0 -0.26486 -0.25352 > > ## For Instance ACF(x) at lag 1 is Corr(x(t),x(t+1)): > > > sum(x[1:9]*x[2:10])/sum(x^2) > [1] -0.2648633 > > ## whereas CCF(x,y) at lag 1 is Corr(x(t),y(t-1)) > > ccf(x,y,lag=2,plot=F) > > Autocorrelations of series 'X', by lag > >-2 -1 0 1 2 > -0.139 0.593 -0.377 -0.382 0.116 > > > sum(x[1:9]*y[2:10])/sqrt(sum(x^2)*sum(y^2)) > > [1] 0.5930216 > > > sum(x[2:10]*y[1:9])/sqrt(sum(x^2)*sum(y^2)) > [1] -0.3822885 > > from a quick survey on textbooks (Brockwell and Davis, Chatfield, > Fuller) it looks like different authors use different conventions so > that I think that it would be nice to clarify this in the > documentation. > > Ciao > > Simone > > > R.version > _ > platform i386-pc-mingw32 > arch i386 > os mingw32 > system i386, mingw32 > status beta > major 2 > minor 4.0 > year 2006 > month 09 > day20 > svn rev39421 > language R > version.string R version 2.4.0 beta (2006-09-20 r39421) > > > Sys.getlocale() > [1] "LC_COLLATE=English_United States.1252;LC_CTYPE=English_United > States.1252;LC_MONETARY=English_United > States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252" > > > __ > > Simone Giannerini > Dipartimento di Scienze Statistiche "Paolo Fortunati" > Universita' di Bologna > Via delle belle arti 41 - 40126 Bologna, ITALY > Tel: +39 051 2098262 Fax: +39 051 232153 > > __ > 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] Fwd: Selfstarting models for soil hydrology using R
The traditional way to handle something like this is to develop your own package for R, possibly even consisting of this one example with your documentation using the standard R documentation protocol. Instructions for how to do this are contained in the "Writing R Extensions" manual, which is the upper right option from help.start(). An alternative would be to add that to the R Wiki. Hope this helps. Spencer Graves CHRISTIAN OMUTO wrote: >> Dear, >> I have developed and tested some models in soil >> hydrology with NLME library in R. I want to ask >> if it could be possible to submit this to the NLME >> library (with sample data) as a toolbox or something >> so >> that anyone downloading new components of new >> versions >> of R may simply call (say >> SSbrookscorey function to predict water retention in >> the same way someone can call SSlogis to predict >> logistic function in the current version)? I would >> be >> grateful for your support. I can also give in-depth >> description and capabilities for white papers >> concerning the applications of R in soil hydrology. >> Please advice me. >> Dr. Christian Thine, >> University of Nairobi, Kenya. >> >> >> __ >> Do You Yahoo!? >> > > >> protection around >> http://mail.yahoo.com >> >> > > __ > 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] [R] RODBC ERROR on Rcmdr install
Dear Vittorio, Thanks for the clarification. This raises two questions: (1) If a *nix system has an ODBC driver, can one then read Excel, Access, and dBase data sets via RODBC (which is what the Rcmdr menu item in question provides for)? (2) If so, is there a way for me to detect whether unixODBC is present, or would I have to rely, e.g., on a user-set option? I'm moving this message to the r-devel list. Regards, John John Fox Department of Sociology McMaster University Hamilton, Ontario Canada L8S 4M4 905-525-9140x23604 http://socserv.mcmaster.ca/jfox > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of vittorio > Sent: Saturday, September 30, 2006 12:40 PM > To: r-help@stat.math.ethz.ch > Subject: Re: [R] RODBC ERROR on Rcmdr install > > Alle 22:55, venerdì 29 settembre 2006, John Fox ha scritto: > > As I understand it, RODBC isn't useful on non-Windows > systems, since > > the necessary ODBC drivers aren't available. (Someone will > correct me, > > I'm sure, if I don't have that entirely straight.) The > RODBC package > > is used in the Rcmdr to read Excel and some other files > under Windows; > > in the latest version of the Rcmdr, you won't even see this > menu item > > in non-Windows systems. > > As a matter of fact RODBC can be profitably used under *nix > OS together with unixODBC to connect to many DBs. > I've been using RODBC with unixODBC on linux, freebsd and win > xp to connect smoothly to postgresql, mysql and oracle > (somewhat tricky to me under *nix, you need ** to buy ** a > driver) and I know that connections are possible to many > other *nix DBs under *nix itself. > > Ciao > Vittorio > > __ > R-help@stat.math.ethz.ch mailing list > https://stat.ethz.ch/mailman/listinfo/r-help > PLEASE do read the posting guide > http://www.R-project.org/posting-guide.html > and provide commented, minimal, self-contained, reproducible code. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] RODBC ERROR on Rcmdr install
John et al, First, RODBC is indeed quite useful under Linux and I use it to connect to an Oracle 10g server running on RHEL. Oracle provides FREE Linux ODBC drivers that support this functionality: http://www.oracle.com/technology/software/tech/oci/instantclient/htdocs/linuxsoft.html That same scenario will be in place for any database provider that offers a native Linux ODBC driver for their application. unixODBC by itself is only half of the solution. With respect to Excel and Access under Linux, there are several options, none of which include ODBC, since a certain large software company in the northwestern U.S. has no incentive to provide ODBC drivers for competitive OSs. For Excel, one can of course export data to ASCII files, which includes the use of OO.org's Calc application under Linux, which in turn supports the reading and writing of Excel format files. In addition, there is the 'gdata' package on CRAN which provides the read.xls() function. For Access, about the only things that I am familiar with under Linux are the MDB Tools package: http://mdbtools.sourceforge.net and the Easysoft ODBC-ODBC bridge product: http://www.easysoft.com/products/data_access/odbc_odbc_bridge/index.html The former is in some stage of being incorporated into OO.org's suite of applications to enable the manipulation of Access MDB files within that environment. More information on that is available here: http://dba.openoffice.org/ For dBase, the only things that I have seen besides R's 'foreign' package are the DataDirect ODBC suite: http://www.componentsource.com/products/515702/18763/summary.html and the 'dbf' converter: http://berg-systeme.de/dbf.html With respect to the detection of unixODBC and the requisite client drivers, there are multiple system and user specific files where such information may be available. These include: /etc/odbc.ini /etc/odbcinst.ini ~/.odbc.ini (User specific) These would correspond to System and User DSN's. The use or lack thereof for any of these files, will be highly dependent upon how the drivers were installed. One of the other solutions that is evolving is JDBC, which is Java based. However, I have seen mixed reports of success using that interface, and I don't recall seeing any support for this in R as of yet, though I may certainly be wrong. You might want to move this thread yet again, over to the r-sig-DB list, where you may find more robust solutions and a DB focused constituency. HTH, Marc Schwartz On Mon, 2006-10-02 at 09:10 -0400, John Fox wrote: > Dear Vittorio, > > Thanks for the clarification. This raises two questions: (1) If a *nix > system has an ODBC driver, can one then read Excel, Access, and dBase data > sets via RODBC (which is what the Rcmdr menu item in question provides for)? > (2) If so, is there a way for me to detect whether unixODBC is present, or > would I have to rely, e.g., on a user-set option? > > I'm moving this message to the r-devel list. > > Regards, > John > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of vittorio > > Sent: Saturday, September 30, 2006 12:40 PM > > To: r-help@stat.math.ethz.ch > > Subject: Re: [R] RODBC ERROR on Rcmdr install > > > > Alle 22:55, venerdì 29 settembre 2006, John Fox ha scritto: > > > As I understand it, RODBC isn't useful on non-Windows > > systems, since > > > the necessary ODBC drivers aren't available. (Someone will > > correct me, > > > I'm sure, if I don't have that entirely straight.) The > > RODBC package > > > is used in the Rcmdr to read Excel and some other files > > under Windows; > > > in the latest version of the Rcmdr, you won't even see this > > menu item > > > in non-Windows systems. > > > > As a matter of fact RODBC can be profitably used under *nix > > OS together with unixODBC to connect to many DBs. > > I've been using RODBC with unixODBC on linux, freebsd and win > > xp to connect smoothly to postgresql, mysql and oracle > > (somewhat tricky to me under *nix, you need ** to buy ** a > > driver) and I know that connections are possible to many > > other *nix DBs under *nix itself. > > > > Ciao > > Vittorio > > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] 2.3.1: interacting bugs in load() and gzfile() (PR#9271)
Hello,
If repeated calls are made to save() using the same pre-opened gzfile
connection to a file, and then the connection is closed, the objects
saved by the second and subsequent calls are not correctly restored by
repeated calls to load() with a new gzfile connection to the same file.
What follows are a session exposing the bugs, analysis (see ANALYSIS),
patches (see PATCHES), and a session showing correct behaviour after
patching (see FIXED). The problematic code is still present in the
trunk of the svn repository.
This is really due to two minor bugs, but because they interact,
I'm submitting this as one report.
Regards,
John Brzustowski
THE BUGS (with comments inserted)
> sessionInfo()
Version 2.3.1 (2006-06-01)
i686-pc-linux-gnu
attached base packages:
[1] "methods" "stats" "graphics" "grDevices" "utils" "datasets"
[7] "base"
## create two objects and save them to a gzfile:
> x <- 1:10
> y <- x^2
> f <- gzfile("tmp.dat", "wb")
> save(x, file=f)
## notice where the second object will be written:
> seek(f, NA)
[1] 88
> save(y, file=f)
> close(f)
## open the file and try to load the two objects, one at a time
> f <- gzfile("tmp.dat", "rb")
> e <- new.env()
> load(f,e)
> ls(e)
[1] "x"
## x was loaded correctly, but the connection has been closed:
> f
descriptionclass mode text
"gzcon(tmp.dat)" "gzcon" "rb" "binary"
opened can readcan write
"closed" "yes" "no"
## (see ANALYSIS)
## Try again:
> load(f,e)
Warning message:
this is already a gzcon connection in: gzcon(con, level, allowNonCompressed)
> ls(e)
[1] "x"
## why the warning?
## and why was nothing apparently read this time?
> f
descriptionclass mode text
"gzcon(tmp.dat)" "gzcon" "rb" "binary"
opened can readcan write
"opened""yes" "no"
> load(f,e)
Warning message:
this is already a gzcon connection in: gzcon(con, level, allowNonCompressed)
> ls(e)
[1] "x" "y"
## this time, y was read correctly, but again why the warning?
> f
descriptionclass mode text
"gzcon(tmp.dat)" "gzcon" "rb" "binary"
opened can readcan write
"closed""yes" "no"
##
## try again, but first seek on the connection to the location of the second
object
> close(f)
> f <- gzfile("tmp.dat", "rb")
> e <- new.env()
> seek(f,88)
[1] 0
> load(f,e)
> ls(e)
[1] "x"
## this should have loaded the object "y", which according to the earlier call
to seek()
## begins at file offset 88.
ANALYSIS
There are two minor bugs here:
1. The internal function loadFromConnection() incorrectly closes a
connection that was already open when it was called, instead of
closing a connection that was *not* already open.
2. gzfile() sets a class of its return value to "file", rather than
"gzfile":
> f <- gzfile("whatever.gz", "wb")
> class(f)
[1] "file" "connection"
In contrast, bzfile() exhibits correct behaviour:
> f2<-bzfile("more.bz2", "wb")
> class(f2)
[1] "bzfile" "connection"
This prevents load() from noticing that the connection passed to it is already
a gzfile, since it tests for inheritance from class "gzfile". Therefore,
load() always re-opens the gzfile connection with gzcon(), which causes
reading to proceed from the beginning of the file, regardless of any seek() on
the original gzfile connection. This reopening of a gzfile with gzcon() causes
the warning, and prevents the seek() before the load() from having any effect.
Interaction: because (with bug 2) load() always reopens a gzfile
connection, bug 1's effect is to not close that reopened connection.
Ironically, this allows (with warnings) objects from multiple calls to save()
to be
restored by multiple calls to load(), as demonstrated by the
section in the session above, provided load() is
being
called with a filename or closed connection rather than an open gzfile
connection.
PATCHES:
for bug 1:
diff -u R-2.3.1.original/src/main/saveload.c R-2.3.1/src/main/saveload.c
--- R-2.3.1.original/src/main/saveload.c2006-04-09 18:19:51.0
-0400
+++ R-2.3.1/src/main/saveload.c 2006-10-02 13:10:21.0 -0400
@@ -2301,6 +2301,7 @@
PROTECT(res = RestoreToEnv(R_Unserialize(&in), aenv));
if (wasopen) {
endcontext(&cntxt);
+} else {
con->close(con);
}
UNPROTECT(1);
for bug 2:
diff -u R-2.3.1.original/src/main/connections.c R-2.3.1/src/main/connections
Re: [Rd] Help for methods
The convention for documenting S4 methods provides a general way to get
the documentation for a method, given the name of the function and the
name(s) of the classes in the signature:
method?"FUN,CLASS1,CLASS2,..."
where FUN is the name of the function and CLASS1, etc. are the names of
the classes in the method signature.
For example,
> method?"show,traceable"
gives the documentation for the show() method for class "traceable".
For a truly excruciating example,
> method?"[,sparseMatrix,index,missing,logical"
gives the documentation for the corresponding method in the Matrix
package ("I'm not making this up you know", as Anna Russell would say).
So the mechanism is obscure and unfriendly, to say the least, but it is
general.
It would be nice to have a decent user interface. Actually, by
combining the code for showMethods() and the mechanism above, one could
have a fairly decent menu-driven scheme. (I came to the second example
above by first doing showMethods("[") and then copying classes from one
line of the output--clearly the software could do this better than the
human).
Duncan Murdoch wrote:
> On 9/30/2006 1:17 AM, hadley wickham wrote:
>
>>> Yes, I agree that the current help system doesn't work very well on S3
>>> methods. But I don't know how to fix it. I think the only way it could
>>> know what to do on a construction like
>>>
>>> ?summary(lm(...))
>>>
>>> would be to actually evaluate summary(lm(...)) (or maybe just lm(...)),
>>> and I think that would be a huge mistake in the user interface. Some
>>> functions have side effects, and you don't want to evaluate them unless
>>> the user asks you to. Asking for help on something should give you
>>> help, it shouldn't do the thing.
>>>
>> I keep flipping back and forth on whether or not that's a problem. I
>> agree that it's not desirable, but may be an ok compromise in
>> principle. How does the S4 help search work?
>>
>
> See the .helpForCall function in utils. It would recognize that the
> function was an S4 generic, and then work out the signature and look for
> matching help. I think working out the signature in the case above
> would require it to call lm(...). So there's a precedent for what I
> called a "huge mistake": maybe it's not so huge...
>
> Duncan Murdoch
>
>
>
>
>
>>> Do you have an actual suggestion for a change to the current behaviour?
>>>
>> One obvious heuristic (which I used with the hints function I wrote a
>> while back) is to iterate through the classes of the first argument
>> looking for functions (with documentation) of the form generic.class1,
>> generic.class2 etc.
>>
>> Obviously this will fail for functions that don't dispatch on the
>> first method, but there probably aren't that many.
>>
>> Hadley
>>
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] documenation duplication and proposed automatic tools
I've been looking at documenting S4 classes and methods, though I have a feeling many of these issues apply to S3 as well. My impression is that the documentation system requires or recommends creating basically the same information in several places. I'd like to explain that, see if I'm correct, and suggest that a more automated framework might make life easier. PROBLEM Consider a class A and a method foo that operates on A. As I understand it, I must document the generic function foo (or ?foo will not produce a response) and the method foo (or methods ? foo will not produce a response). Additionally, it appears to be recommended that I document foo in the Methods section of the documentation for class A. Finally, I may want to document the method foo with specific arguments (particularly if if uses "unusual" arguments, but presumably also if the semantics are different in a class that extends A). This seems like a lot of work to me, and it also seems error prone and subject to synchronization errors. R CMD check checks vanilla function documentation for agreement with the code, but I'm not sure that method documentation in other contexts gets much help. To complete the picture, suppose there is a another function, "bar", that operates on A. B extends A, and reimplements foo, but not bar. I think the suggestion is that I go back and add the B-flavored method foo to the general methods documentation for foo. I also have a choice whether I should mention bar in the documentation for the class B. If I mention it, it's easier for the reader to grasp the whole interface that B presents. However, I make it harder to determine which methods implement new functionality. SOLUTION There are a bunch of things users of OO systems typically want to know: 1) the relations between classes 2) the methods implemented by a class (for B, just foo) 3) the interface provided by a class (for B, foo and bar) 4) the various implementations of a particular method All of these can be discovered dynamically by the user. The problem is that current documentation system attempts to reproduce this dynamic information in static pages. prompt, promptClass and promptMethods functions generate templates that contain much of the information (or at least there supposed to; they seem to miss stuff for me, for example saying there are no methods when there are methods). This is helpful, but has two weaknesses. First, the class developer must enter very similar information in multiple places (specifically, function, methods, and class documentation). Second, that information is likely to get dated as the classes are modified and extended. I think it would be better if the class developer could enter the information once, and the documentation system assemble it dynamically when the user asks a question. For example, if the user asks for documentation on a class, the resulting page would be contstructed by pulling together the class description, appropriate method descriptions, and links to classes the focal class extends (as well, possibly, as classes that extend it). Similarly, a request for methods could assemble a page out of the snippets documenting the individual methods, including links to the relevant classes. I realize that implementing this is not trivial, and I'm not necessarily advocating it as a priority. But I wonder how it strikes people. -- Ross Boylan wk: (415) 514-8146 185 Berry St #5700 [EMAIL PROTECTED] Dept of Epidemiology and Biostatistics fax: (415) 514-8150 University of California, San Francisco San Francisco, CA 94107-1739 hm: (415) 550-1062 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] More strange [[ behaviour
Hi,
> setClass("MyList", "list")
[1] "MyList"
> a <- new("MyList")
> a
An object of class "MyList"
list()
> setMethod("[[", "MyList", function(x, i, j, ...) cat("Just testing\n"))
> a[[]]
Just testing
> a[[1]]
Just testing
> a[[a=1]]
Just testing
> a[[b=1]]
Just testing
...
> a[[v=1]]
Just testing
> a[[w=1]]
Just testing
> a[[x=1]]
Error in a[[x = 1]] : subscript out of bounds
> a[[y=1]]
Just testing
> a[[z=1]]
Just testing
Can someone explain me why the "[[x=1]]" case is treated differently?
Cheers,
H.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] More strange [[ behaviour
On 10/2/2006 3:21 PM, Herve Pages wrote:
> Hi,
>
>> setClass("MyList", "list")
> [1] "MyList"
>> a <- new("MyList")
>> a
> An object of class "MyList"
> list()
>> setMethod("[[", "MyList", function(x, i, j, ...) cat("Just testing\n"))
>> a[[]]
> Just testing
>> a[[1]]
> Just testing
>> a[[a=1]]
> Just testing
>> a[[b=1]]
> Just testing
> ...
>> a[[v=1]]
> Just testing
>> a[[w=1]]
> Just testing
>> a[[x=1]]
> Error in a[[x = 1]] : subscript out of bounds
>> a[[y=1]]
> Just testing
>> a[[z=1]]
> Just testing
>
> Can someone explain me why the "[[x=1]]" case is treated differently?
Indexing is a function call, with arguments x, i, j, ... . If you use
y=1, you're setting something in the "..." part of the arg list. If you
say x=1, you're setting the first arg, but because a[[x=1]] is the same
as "[["(a, x=1), it is going to evaluate it as "[["(x=1, i=a) and try to
index 1 by a instead of a by 1.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] More strange [[ behaviour
Duncan Murdoch wrote: > On 10/2/2006 3:21 PM, Herve Pages wrote: >>> a[[x=1]] >> Error in a[[x = 1]] : subscript out of bounds >> > > Indexing is a function call, with arguments x, i, j, ... . If you use > y=1, you're setting something in the "..." part of the arg list. If > you say x=1, you're setting the first arg, but because a[[x=1]] is the > same as "[["(a, x=1), it is going to evaluate it as "[["(x=1, i=a) and > try to index 1 by a instead of a by 1. Hi Duncan, Right, thanks for the explanation and sorry for not paying more attention. Best, H. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] documenation duplication and proposed automatic tools
Hi. Far from complete, but some sketches on a solution is in the
Rdoc-to-Rd translator of the R.oo package. I, the author, never made
this very public because it uses a very ugly parser etc for it, but
the basics is there and I use it to generate \usage{} statements and
class hierarchies automatically, import example code and so on. I
never have worry about consistency between code and Rd usage because
they are generated automatically.
An alternative to generate dynamic help pages in HTML (or other
formats too) is provided by the R.rsp package which allows you to
write things like:
http://www.w3.org/TR/REC-html40/loose.dtd";>
<%title="R Server Pages - Hello world!"%>
<%=title%>
<%=title%>
This is an example of an RSP page. This HTML page was generated
from an RSP file on a <%=format(Sys.time(), "%A")%> at
<%=format(Sys.time(), "%H:%M:%S")%>.
and have R to translate it to HTML code. It even got a built-in HTTP
daemon (from Rpad) to do this automatically. This would allow you to
generate instant help on classes and objects etc.
/Henrik
On 10/2/06, Ross Boylan <[EMAIL PROTECTED]> wrote:
> I've been looking at documenting S4 classes and methods, though I have a
> feeling many of these issues apply to S3 as well.
>
> My impression is that the documentation system requires or recommends
> creating basically the same information in several places. I'd like to
> explain that, see if I'm correct, and suggest that a more automated
> framework might make life easier.
>
> PROBLEM
>
> Consider a class A and a method foo that operates on A. As I understand
> it, I must document the generic function foo (or ?foo will not produce a
> response) and the method foo (or methods ? foo will not produce a
> response). Additionally, it appears to be recommended that I document
> foo in the Methods section of the documentation for class A. Finally, I
> may want to document the method foo with specific arguments
> (particularly if if uses "unusual" arguments, but presumably also if the
> semantics are different in a class that extends A).
>
> This seems like a lot of work to me, and it also seems error prone and
> subject to synchronization errors. R CMD check checks vanilla function
> documentation for agreement with the code, but I'm not sure that method
> documentation in other contexts gets much help.
>
> To complete the picture, suppose there is a another function, "bar",
> that operates on A. B extends A, and reimplements foo, but not bar.
>
> I think the suggestion is that I go back and add the B-flavored method
> foo to the general methods documentation for foo. I also have a choice
> whether I should mention bar in the documentation for the class B. If I
> mention it, it's easier for the reader to grasp the whole interface that
> B presents. However, I make it harder to determine which methods
> implement new functionality.
>
> SOLUTION
>
> There are a bunch of things users of OO systems typically want to know:
> 1) the relations between classes
> 2) the methods implemented by a class (for B, just foo)
> 3) the interface provided by a class (for B, foo and bar)
> 4) the various implementations of a particular method
>
> All of these can be discovered dynamically by the user. The problem is
> that current documentation system attempts to reproduce this dynamic
> information in static pages. prompt, promptClass and promptMethods
> functions generate templates that contain much of the information (or at
> least there supposed to; they seem to miss stuff for me, for example
> saying there are no methods when there are methods). This is helpful,
> but has two weaknesses. First, the class developer must enter very
> similar information in multiple places (specifically, function, methods,
> and class documentation). Second, that information is likely to get
> dated as the classes are modified and extended.
>
> I think it would be better if the class developer could enter the
> information once, and the documentation system assemble it dynamically
> when the user asks a question. For example, if the user asks for
> documentation on a class, the resulting page would be contstructed by
> pulling together the class description, appropriate method descriptions,
> and links to classes the focal class extends (as well, possibly, as
> classes that extend it). Similarly, a request for methods could
> assemble a page out of the snippets documenting the individual methods,
> including links to the relevant classes.
>
> I realize that implementing this is not trivial, and I'm not necessarily
> advocating it as a priority. But I wonder how it strikes people.
>
> --
> Ross Boylan wk: (415) 514-8146
> 185 Berry St #5700 [EMAIL PROTECTED]
> Dept of Epidemiology and Biostatistics fax: (415) 514-8150
> University of California, San Francisco
> San Francisco, CA 94107-1739 hm: (415) 550-1062
>
> _
[Rd] Maybe a bug in warning() for condition objects?
I'm using R-2.3.1 but the code in question is the same in the
01-Oct-2006 snapshot for release 2.4.0. I'd like to evaluate an
expression, catching errors and handling them as warnings. My first
attempt:
x <- tryCatch(lm(xyzzy), error=warning)
didn't work; the error is still treated as an error, not a warning.
So I thought, hmmm, the condition is still classed as an "error", how
about if I change that:
as.warning <- function(e) warning(simpleWarning(e$message,e$call))
x <- tryCatch(lm(xyzzy), error=as.warning)
Still no luck. But this works:
as.warning <- function(e) .signalSimpleWarning(e$message,e$call)
x <- tryCatch(lm(xyzzy), error=as.warning)
I think the problem here is that warning() contains the code:
withRestarts({
.Internal(.signalCondition(cond, message, call))
.Internal(.dfltStop(message, call))
}, muffleWarning = function() NULL)
i.e., the default action is .dfltStop(), not .dfltWarn(). Is this
intentional? It seems to make more sense to me for the default action
for conditions passed to warning() to be .dfltWarn(), but I may well
be misunderstanding something.
-- David Hinds
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
