1 Jun 2008 17:41

### [Rd] suggested addition to fft man page

Hi,

May I request that the formula for fft() be included in the man page?
This is the second time I had to check what fft() does... In fact,
fft.Rd has
%%
%% Here, we should really have a nice  \deqn{}{} giving the definition
%% of the DFT !
%%
Below is a suggested snippet (not necessarily "nice") to be added to
fft.Rd; please feel free to improve it.

%%---begin{hiroyuki}
\code{y <- fft(z)} returns
\deqn{y[h] = \sum_{k=1}^n z[k] \exp(-2\pi i (k-1)(h-1)/n)}{%
y[h] = sum_{k=1}^{n} z[k]*exp(-2*pi*1i*(k-1)*(h-1)/n)}
for \eqn{h = 1,\ldots,n}{h = 1, ..., n} where n = \code{length(y)}. If
\code{inverse} is \code{TRUE}, \eqn{\exp(-2\pi\ldots)}{exp(-2*pi...)}
is replaced with \eqn{\exp(2\pi\ldots)}{exp(2*pi...)}.
%%---end{hiroyuki}

h.
p.s. fft.c was not "readable" so i used the following code to check the formula:

# to check fft formula
fft_slow <- function(z, inverse=FALSE) {
n <- length(z)
kdx <- seq(0, n-1)
sgn <- ifelse(inverse, 1, -1)


1 Jun 2008 17:30

### Re: [Rd] NAMESPACE & methods guidance, please

My impression (but just as a user, not an implementer) is that the
NAMESPACE mechanism is intended to search for anything, not just for
methods, as follows:

- look in the namespace itself;
- look in the imports, which are in the parent.env of the namespace;
- look in the base package's namespace.

Period.  This provides a definition of the behavior of functions in the
package that is independent of the dynamically changing contents of the
search list.

But the catch, it seems, is that the third element above, the base
namespace, has the Global namespace as its parent.  As a result, I
believe the search continues through the entire search list, when one is
using exists() or get() in the ordinary way.

The effect is only noticeable, of course, if the object in question is
_not_ found in the first three environments searched. As a result, it's
not widely obvious.  But it does seem, in principle, to violate the
concept of the namespace.

The mechanisms in the methods package that do searching are intended to
use the three-part interpretation of namespaces above; just what if
anything in the changes between 2.7.0 and r-devel would cause the
different results isn't obvious, but if I understand your example, the
current behavior seems as intended.

"Depends" may cause the relevant packages to be put on the search list.
But a subsequent attach or detach could change what objects were found.


1 Jun 2008 20:15

### Re: [Rd] NAMESPACE & methods guidance, please

* On 2008-06-01 at 11:30 -0400 John Chambers wrote:
> My impression (but just as a user, not an implementer) is that the
> NAMESPACE mechanism is intended to search for anything, not just for
> methods, as follows:
>
>  - look in the namespace itself;
>  - look in the imports, which are in the parent.env of the namespace;
>  - look in the base package's namespace.

As described in the R News article [1], the above describes the static
component of the search mechanism, but there is a dynamic component

- look in .GlobalEnv
- look in each package on the search path
- look (again) in base

[1] http://cran.r-project.org/doc/Rnews/Rnews_2003-1.pdf

> Period.  This provides a definition of the behavior of functions in the
> package that is independent of the dynamically changing contents of the
> search list.

I think the dynamic lookup is important.  Consider class Foo and some
methods, like show, for working with Foo instances defined in pkgA.
Further, suppose pkgB imports pkgA and contains a function that
returns a Foo instance.

If a user class library("pkgB") at the prompt, both the developer and
the user would like for methods for dealing with Foo instances to be


2 Jun 2008 11:36

### Re: [Rd] (PR#11537) help (using ?) does not handle trailing whitespace

>>>>> "BDR" == Prof Brian Ripley <ripley <at> stats.ox.ac.uk>
>>>>>     on Fri, 30 May 2008 22:34:28 +0100 (BST) writes:

BDR> I think it is ESS that is parsing this as a help
BDR> request (so it can divert it to an ESS buffer).

BDR> Looks like this is an ESS issue, not an R one.

yes, indeed,  hence much more belonging the ESS-help mailing
list (or the 'ESS-bugs' e-mail alias).
I'm diverting to that list; please keep follow-ups to this
topic off R-devel.

As most ESS users are aware, ESS is "picking up"
?<...> calls, and indeed then calls help() for these.
In R,  '?' has become different from help() more and more,
and it is currently the most urgent open issue in ESS,
that ESS should become much smarter in dealing with '?', the
various 'type ? topic' version and new '??', etc.

Martin Maechler, ETH Zurich

BDR> Using ?"agrep " will fail in R, but that seems correct as there is no
BDR> topic "agrep ".

BDR> On Fri, 30 May 2008, Tim Hesterberg wrote:

>> By whitespace, I mean either a space or tab (preceding the newline).
>>
>> I'm using ESS:


2 Jun 2008 15:22

### Re: [Rd] NAMESPACE & methods guidance, please

(Comment near the bottom of the text.)

Seth Falcon wrote:
> * On 2008-06-01 at 11:30 -0400 John Chambers wrote:
>
>> My impression (but just as a user, not an implementer) is that the
>> NAMESPACE mechanism is intended to search for anything, not just for
>> methods, as follows:
>>
>>  - look in the namespace itself;
>>  - look in the imports, which are in the parent.env of the namespace;
>>  - look in the base package's namespace.
>>
>
> As described in the R News article [1], the above describes the static
> component of the search mechanism, but there is a dynamic component
>
>     - look in .GlobalEnv
>     - look in each package on the search path
>     - look (again) in base
>
> [1] http://cran.r-project.org/doc/Rnews/Rnews_2003-1.pdf
>
>
>> Period.  This provides a definition of the behavior of functions in the
>> package that is independent of the dynamically changing contents of the
>> search list.
>>
>


2 Jun 2008 16:39

### [Rd] Revised help pages for methods package

A number of the help pages have been revised, so far only on the r-devel
version, although the great majority of the revisions apply to 2.7.0 as
well.

Much of the existing documentation is out of date, some of it badly.
package?methods and navigate down through some general pages to
details.  (Not by any means as an introduction to the topic, but for
clarifications and for details.)

I hope eventually to revise most of the pages, but only a dozen or so
have been done at this point (including, however, many of the key
topics).   Another reason for delay was that the new pages reference the
"Software for Data Analysis" book, which was supposed to be out by now,
but is not "quite" (questions on that topic have to go to the publisher).

However, it seems useful to distribute these revisions now, as the
topics come up, for example, in this mailing list fairly often.

John

______________________________________________
R-devel <at> r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


2 Jun 2008 22:29

### Re: [Rd] Request: Documentation of formulae

Mike Prager <mike.prager <at> noaa.gov> wrote:

> I was at a loss to understand the use of "/" until I looked in
> "An Introduction [!] to R," where I found the explanation.
>
> My request is that more complete material on model formulae be
> lifted from "Introduction to R" (or elsewhere) and put into the

I also request the R Core consider remaining "An Introduction to
R" to something like "R User's Guide." It spans 100 pages and
treats many topics far beyond the introductory level. I was
surprised at the wealth of information it contains, and I expect
that I would have checked it first, not last, among available
resources had it been more accurately named.

--

--
Mike Prager, NOAA, Beaufort, NC
* Opinions expressed are personal and not represented otherwise.
* Any use of tradenames does not constitute a NOAA endorsement.

______________________________________________
R-devel <at> r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


3 Jun 2008 05:42

### [Rd] configure.args from install.packages passed on to subsequent update.packages?

>From the help pages I see that there is a configure.args argument to
install.packages, and I am using that successfully. I do not see anything
similar for update.packages(). Does each package keep track of the
configure.args used to build in initially and pass this on to subsequent
updates or I am missing an argument to update.packages?

Thanks,
Mark

--

--
Mark W. Kimpel MD ** Neuroinformatics ** Dept. of Psychiatry
Indiana University School of Medicine

15032 Hunter Court, Westfield, IN 46074

(317) 490-5129 Work, & Mobile & VoiceMail
(317) 663-0513 Home (no voice mail please)

******************************************************************

[[alternative HTML version deleted]]

______________________________________________
R-devel <at> r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


3 Jun 2008 05:56

### [Rd] benchmarking R installations

Recently I posted to this list with a question about using the Intel 10.1
compilers in building R and one response was basically, "why in the heck
would you want to do that?" The answer is that my sysadmin believes that
there will be a performance boost with the Intel vs. Gnu compilers on our
Linux cluster, of which I am one of many users. Wanting to be a good citizen
and use my machine time wisely, I'd of course like to use right tool to
build the most efficient installation of R and associated packages. BTW, we
got R to compile nicely using the settings at the end of this post.

Looking back on previous posts, however, it seems that there is no consensus
as to how to benchmark R. I realize such a task is not trivial, nor
controversial, but does anyone have a set of time-consuming tasks that can
be used to compare R installations? It would seem logical that such a
benchmark would include sub-benchmarks on file access, interpreted intensive
one simple answer. Nevertheless, I'd like to make my usage decisions on
something rather than anedotal claims.

So, does anyone know of a good benchmarking script or would be willing to
contribute one?

And here are the settings we used to compile R with Intel 10.1 compilers:

../configure --prefix=/N/u/mkimpel/R_HOME/R-patched/R-build \
--with-system-zlib=/usr/lib64 --with-system-bzlib=/usr/lib64 \
--with-mpi=/N/soft/linux-rhel4-x86_64/openmpi/1.2.5/intel-64 --with-tcltk \
--with-tcl-config=/N/soft/linux-rhel4-x86_64/tcl8.4.16/lib64/tclConfig.sh \
--with-tk-config=/N/soft/linux-rhel4-x86_64/tk8.4.16/lib64/tkConfig.sh \


3 Jun 2008 07:20

### [Rd] More information on R segfaults, tcltk package, and graphics devices

Dear R-devel -

I have investigated the report I made at
https://stat.ethz.ch/pipermail/r-devel/2008-May/049683.html some more,
and believe I have enough information to warrant an update.  My
sessionInfo() immediately after starting R is at the bottom of this message.

I decided to first concentrate on finding out why I sometimes receive a
segfault while closing a graphics window while the window is redrawing

I do the following code in a --vanilla R session.

library(grid)
library(tcltk)
for(i in seq(0, 1, by = .1)) {
for(j in seq(0, 1, by = .01)) {
angle <- runif(1, 1, 180)
col <- sample(colors(), 1)
pushViewport(viewport(x = i, y= j, width = .1, height = .1,
angle = angle, gp = gpar(col = col)))
grid.rect()
popViewport()
}
}

I then simply resize the X11 window a bit to force a redraw of the
graphic, and then rapidly hit the 'X' close button on the X11 window
while the rectangles are redrawing.  I will often get the behavior that
the window closes and R segfaults.