headers
Hiroyuki Kawakatsu | 1 Jun 2008 17:41
Picon

[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}

Thanks for your consideration,
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)
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Chambers | 1 Jun 2008 17:30
Favicon

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.
(Continue reading)

Permalink | Reply | 502 comments |
headers
Seth Falcon | 1 Jun 2008 20:15
Favicon
Gravatar

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
which adds:

    - 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
(Continue reading)

Permalink | Reply | 1 comment |
headers
maechler | 2 Jun 2008 11:36
Picon
Favicon
Gravatar

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:
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Chambers | 2 Jun 2008 15:22
Favicon

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
> which adds:
>
>     - 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.
>>     
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Chambers | 2 Jun 2008 16:39
Favicon

[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.  
Also, a goal of the revision is that readers could start with 
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
Permalink | Reply | 0 comments |
headers
Mike Prager | 2 Jun 2008 22:29
Picon
Favicon

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
> main online help files. 

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
Permalink | Reply | 5 comments |
headers
Mark Kimpel | 3 Jun 2008 05:42
Picon

[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
Permalink | Reply | 0 comments |
headers
Mark Kimpel | 3 Jun 2008 05:56
Picon

[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
tasks, C intensive tasks, BLAS intensive tasks, etc. You developers know
more about this than I do, but I know enough to realize that there won't be
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 \
--without-x --without-readline --without-iconv \
(Continue reading)

Permalink | Reply | 4 comments |
headers
Erik Iverson | 3 Jun 2008 07:20
Picon

[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 
after resizing it, but seemingly only after loading the tcltk package.

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.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane