[Rd] ?bquote

[Gabor Grothendieck]

?bquote says it returns an expression but, in fact, it typically
(though not always) returns a call object:

> class(bquote(a+b))
[1] "call"

> class(bquote(1))
[1] "numeric"

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Citation of R packages

[John Maindonald]

On 5 Feb 2006, at 2:27 AM, [EMAIL PROTECTED] wrote:

>> On Mon, 30 Jan 2006 10:06:52 +1100 (EST),
>> John Maindonald (JM) wrote:
>
>> The bibtex citations provided by citation() do not
>> work all that well in cases where there is no printed
>> document to reference:
>
> That's why there is a warning at the end that they will need manual
> editing ... IMHO they at least save you some typing effort in many
> cases.

They are certainly a useful start.

>> (1) A version field is needed, as the note field is
>> required for other purposes, currently trying to
>> sort out nuances that cannot be sorted out in the
>> author list (author, compiler, implementor of R version,
>> contributor, ...) and maybe giving a cross-reference
>> to a book or paper that is somehow relevant.
>
> Why should a reference cross-reference another reference? Could you
> give an example?

Where there is a published paper or a book (such as MASS), or a manual
for which a url can be given, my decision was to include that in the  
main
list of references, but not to include references there that were  
references
to the package itself, which as you suggest below can be a reference to
the concatenated help pages.

It seemed anyway useful to have a separate list of packages.  For
consistency, these were always references to the package, with a
cross-reference to any relevant document in the references to papers.

>> (2) Maybe the author field should be more nuanced, or
>> maybe ...
>
> author fields of bibtex entries have a strict format (names separated
> by "and"), what do you mean by "more nuanced"?

Those named in the list of authors may be any combination of: the  
authors
of an R package, the authors of an original S version, the person or  
persons
responsible for an R port, the authors of the Fortran code, compiler 
(s), and
contributors of ideas.

For John Fox's car, citation() gives the following:
 author = {John Fox. I am grateful to Douglas Bates and David  
Firth and Michael Friendly and Gregor Gorjanc and Georges Monette and  
Henric Nilsson and Brian Ripley and Sanford Weisberg and and Achim  
Zeleis for various suggestions and contributions.},

For Rcmdr:
 author = {John Fox and with contributions from Michael Ash and  
Philippe Grosjean and Martin Maechler and Dan Putler and and Peter  
Wolf.},

For car, maybe John Fox should be identified as author.  For Rcmdr,  
maybe the other persons that are named should be added?

For leaps:
 author = {Thomas Lumley using Fortran code by Alan Miller},

It seems reasonable to cite Lumley and Miller as authors.  Should  
there be a note that identifies Miller as the contributor of the  
Fortran code?

Should the name(s) of porters (usually from S) be included as author 
(s)?  Or should their contribution be acknowledged in the note field?  
Or ...

Possibilities are to cite all those individuals as author, or to cite  
John Fox only,
with any combination of no additional information in the note field,  
or using the
note field to explain who did what.  The citation() function leaves  
it unclear who
are to be acknowledged as authors, and in fact

>> (3) In compiling a list of packages, name order seems
>> preferable, and one wants the title first (achieved by
>> relocating the format.title field in the manual FUNCTION
>> in the .bst file
>> (4) manual seems not an ideal name for the class, if
>> there is no manual.
>
> A package always has a "reference manual", the concatenated help pages
> certainly qualify as such and can be downloaded in PDF format from
> CRAN. The ISBN rules even allow to assign an ISBN number to the online
> help of a software package which also can serve as the ISBN number of
> the *software itself* (which we did for base R).

I'd prefer some consistency in the way that R packages are referenced.
Thus, if reference for one package is to the concatenated help pages,
do it that way for all of them.

>> Maybe what is needed is a package or suchlike class,
>> and several alternative .bst files that handle the needed
>> listings.
>
>> I know at least one other person who is wrestling with
>> this, and others on this list must be wrestling with it.
>
> I am certainly open for discussions and any suggestions for
> improvements, but it must be within the standard bibtex entry types,
> we cannot write our own entry types and .bst files. Many journals
> require the usage of their own (or standard) bibtex styles, and the
> entries we produce must work with those. If R creates nonstandard
> bibtex entries even more manual work will be necessary in many
> cases.
>
> I have no definitive bibtex reference at hand, but the natbib style
> files (a very popular collection of bibtex styles, at least I
> definitely want to be compatible with those) define
>
>  article
>  book
>  booklet
>  conference  (= alias for inproceedings)
>  inbook
>  incollection
>  inproceedings
>  manual
>  mastersthesis
>  misc
>  phdthesis
>  proceedings
>  techreport
>  unpublished
>
>

[Rd] R CMD build: "Subdirectory 'R' contains invalid file names"

[Henrik Bengtsson]

Hi, I get

* excluding invalid files from 'R.oo'
Subdirectory 'R' contains invalid file names:
  attachLocally.Object.Rex Exception.Rex extend.default.Rex
  InternalErrorException.reportBug.Rex Package.Rex Person.Rex Rdoc.Rex
  setMethodS3.Rex StaticFields.Rex

when running R CMD build in R v2.3.0 devel.  I do understand what is
going on.  In my *.R files I keep so called Rdoc comments which in
their simplest form are Rd code wrapped up in plain comments.  These
are compiled into Rd files written to ../man/ (I do this prior to
building packages).  Rdoc also supports inclusion of other files, e.g.
@include "Person.Rex" to include example code.

With this structure I can, when I develop/maintain a package, have
/R/ as the working directory, modify my *.R files and re-source
them from within R.  Since I keep all my Rd example code in separate
*.Rex files, I can easily rerun/test these by sourcing them too.  I
find this very convenient.

In previous versions, the *.Rex files was included when building a
source distribution of a package.  In R v2.3.0 they are excluded. 
However, I would like to distribute the *.Rex files with my
source-code package too (so I do not have to keep another type of
source distribution).  Note that these files are only needed for
further development of the package, but *not* to install the package
from source (since their contents is already incorporated in the Rd
files).  They are also not of interest to the end-user.

My question is how to incorporate the *.Rex files?  Here are some
ideas, that I would like to have some feedback on:

1) Put them in /R/Rex/*.Rex.  However, Section 1.1.4 in Writing R
Extensions suggest that subdirectories of R/ may only(?) be named
'windows' or 'unix'.

2) Rename them to /R/*.in, cf. Section 1.1.4.  Is this the
purpose of *.in files?  Will it have side effects?

3) Put the in /inst//*.Rex.  This will work, but then they
will also be install and available in system.file("",
package="").  Not a big problem, but not what I want.

4) To avoid (3), put the in //*.Rex, i.e. at the top level
directory.  Is this allowed?  Section 1.1.4 says "Note that [...]
information files at the top level of the package will not be
installed". Does this mean that they will be included in the source
distribution and what about top level directories?

5) Put the in /src/*.Rex.  Can src/ be used this way too?

6) Ask R-core to revert back to pre-R v2.3.0 and allow other files in
the R/ directory too.  Are more people than I interested in this?

I realize I can test the above by trial and error, but I will still
not be sure what is the right approach here.  Comments/feedback is
appreciated.

Thanks

Henrik

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] ATLAS threaded 64 bit Opteron build for R: need -fPIC

[Amit Aronovitch]

Hi,

 Sorry for sending such a late reply, and for being abit OT.

  I've been trying to compile 64 bit ATLAS for numpy
(http://numeric.scipy.org/ ),
and so far this thread is the most useful one I could google up - thanks!.
  I encountered similiar problems, and so far could not get a .a
linkable to numpy
(comparing to your post - it seems I might have forgotten to add the
-fPIC for the
F77FLAGS or MMFLAGS).

 Also, I'm having trouble with the ATLAS lapack. To get a usable lib,
one has to
merge it with a full lapack implementation (as described in the ATLAS
errata).
 However, I'm using RHEL4, and their installed liblapack.a seems to have
been compiled
without -fPIC, so the merged library is unlinkable to numpy's .so. Is
there a way to use Redhat's
installed liblapack.so?

 Few questions about your compiler flags:

1) Is there a reason to compile with -O rather than -O3?
 (did you try and encounter some problem, or found no major performance
difference)
2) I see you use -mfpmath=387 - does this work better than sse2 (which
seems to be
 the default)? How about the "sse,387" option - should I try that?
 
Martin Maechler wrote:

>/ "PD" == Peter Dalgaard >
/>/  >> "PD" == Peter Dalgaard 
>> on 26 Feb 2004 15:44:16 +0100 writes:
>
>PD> Douglas Bates  writes:
>>> Have you tried configuring R with Goto's BLAS
>>> http://www.cs.utexas.edu/users/kgoto/
>>> 
>>> I haven't worked with Opteron or Athlon64 computers but I understand
>>> that Goto's BLAS are very effective on those machines.  Furthermore
>>> Goto's BLAS are (only) available as .so libraries so you don't need to
>>> mess with creating the .so version.
>
>PD> I tried it, yes. Somewhat to my surprise, it seemed to be not quite as
>PD> fast as the threaded ATLAS, but I wasn't very systematic about the
>PD> benchmarking.
>
>PD> (and the Goto items have license issues, which get in the way for
>PD> binary distributions.)
>
>Thanks a lot, Peter, Brian, Doug, for your feedbacks!
>In the mean time, I have three running versions of R(-devel) on
>the 64-Opteron
>- "plain"
>- linked against threaded GOTO
>- linked against threaded (static) ATLAS  (using -fPIC for compilation;
>  "large" Rlapack)
>and I find that GOTO is faster than ATLAS
>consistently (between ~ 5-20%) for several tests
>(square matrices; %*% and solve).
>ATLAS is still an order of magnitude faster than "plain" for
>3000x3000 matrices.
>
>Here are somewhat repeatable "ATLAS for R" build instructions:
>
> 1. get ATLAS source; unpack
> 2. make : use defaults and "express" installation
> 3. Before "make install ...", edit the  Make. file:
>add "-fPIC" to three places, namely  F77FLAGS, CCFLAG0, and MMFLAGS:
>which in case of the "threaded Opteron" architecture, leads to
>the three new lines
>   F77FLAGS = -fPIC -fomit-frame-pointer -O -m64
>
>   CCFLAG0 = -fPIC -fomit-frame-pointer -O -mfpmath=387 -m64
>
>   MMFLAGS = -fPIC -fomit-frame-pointer -O -mfpmath=387 -m64
>in the file   Make.Linux_HAMMER64SSE2_2
>
> 4. make install arch=Linux_HAMMER64SSE2_2
>
> 5. Sym.link the ATLAS libraries into /usr/local/lib:
>
>cd /usr/local/lib
>ln -s /lib/Linux_HAMMER64SSE2_2/lib* .
>
> 6. (needed for runtime!):
>Use environment variable LD_LIBRARY_PATH=/usr/local/lib
>
>
>Note that I haven't built *.so (shared) libraries yet.
 /

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] R CMD build: "Subdirectory 'R' contains invalid file names"

[Kurt Hornik]

> Henrik Bengtsson writes:

> Hi, I get
> * excluding invalid files from 'R.oo'
> Subdirectory 'R' contains invalid file names:
>   attachLocally.Object.Rex Exception.Rex extend.default.Rex
>   InternalErrorException.reportBug.Rex Package.Rex Person.Rex Rdoc.Rex
>   setMethodS3.Rex StaticFields.Rex

> when running R CMD build in R v2.3.0 devel.  I do understand what is
> going on.  In my *.R files I keep so called Rdoc comments which in
> their simplest form are Rd code wrapped up in plain comments.  These
> are compiled into Rd files written to ../man/ (I do this prior to
> building packages).  Rdoc also supports inclusion of other files, e.g.
> @include "Person.Rex" to include example code.

> With this structure I can, when I develop/maintain a package, have
> /R/ as the working directory, modify my *.R files and re-source
> them from within R.  Since I keep all my Rd example code in separate
> *.Rex files, I can easily rerun/test these by sourcing them too.  I
> find this very convenient.

> In previous versions, the *.Rex files was included when building a
> source distribution of a package.  In R v2.3.0 they are excluded. 
> However, I would like to distribute the *.Rex files with my
> source-code package too (so I do not have to keep another type of
> source distribution).  Note that these files are only needed for
> further development of the package, but *not* to install the package
> from source (since their contents is already incorporated in the Rd
> files).  They are also not of interest to the end-user.

Henrik,

I am not sure I fully understand the issue.

The 

   Note that these files are only needed for further development of the
   package

suggests that these files are only needed for your local master sources,
but not in the source package created by R CMD build.  If this is the
case, then you really don't have to do anything, because R CMD build
will happily exclude these files, and R CMD check on the .tar.gz will no
longer find them.

Best
-k

> My question is how to incorporate the *.Rex files?  Here are some
> ideas, that I would like to have some feedback on:

> 1) Put them in /R/Rex/*.Rex.  However, Section 1.1.4 in Writing R
> Extensions suggest that subdirectories of R/ may only(?) be named
> 'windows' or 'unix'.

> 2) Rename them to /R/*.in, cf. Section 1.1.4.  Is this the
> purpose of *.in files?  Will it have side effects?

> 3) Put the in /inst//*.Rex.  This will work, but then they
> will also be install and available in system.file("",
> package="").  Not a big problem, but not what I want.

> 4) To avoid (3), put the in //*.Rex, i.e. at the top level
> directory.  Is this allowed?  Section 1.1.4 says "Note that [...]
> information files at the top level of the package will not be
> installed". Does this mean that they will be included in the source
> distribution and what about top level directories?

> 5) Put the in /src/*.Rex.  Can src/ be used this way too?

> 6) Ask R-core to revert back to pre-R v2.3.0 and allow other files in
> the R/ directory too.  Are more people than I interested in this?

> I realize I can test the above by trial and error, but I will still
> not be sure what is the right approach here.  Comments/feedback is
> appreciated.

> Thanks

> Henrik

> __
> 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 CMD build: "Subdirectory 'R' contains invalid file names"

[Henrik Bengtsson]

Hi,

On 2/10/06, Kurt Hornik <[EMAIL PROTECTED]> wrote:
> > Henrik Bengtsson writes:
>
> > Hi, I get
> > * excluding invalid files from 'R.oo'
> > Subdirectory 'R' contains invalid file names:
> >   attachLocally.Object.Rex Exception.Rex extend.default.Rex
> >   InternalErrorException.reportBug.Rex Package.Rex Person.Rex Rdoc.Rex
> >   setMethodS3.Rex StaticFields.Rex
>
> > when running R CMD build in R v2.3.0 devel.  I do understand what is
> > going on.  In my *.R files I keep so called Rdoc comments which in
> > their simplest form are Rd code wrapped up in plain comments.  These
> > are compiled into Rd files written to ../man/ (I do this prior to
> > building packages).  Rdoc also supports inclusion of other files, e.g.
> > @include "Person.Rex" to include example code.
>
> > With this structure I can, when I develop/maintain a package, have
> > /R/ as the working directory, modify my *.R files and re-source
> > them from within R.  Since I keep all my Rd example code in separate
> > *.Rex files, I can easily rerun/test these by sourcing them too.  I
> > find this very convenient.
>
> > In previous versions, the *.Rex files was included when building a
> > source distribution of a package.  In R v2.3.0 they are excluded.
> > However, I would like to distribute the *.Rex files with my
> > source-code package too (so I do not have to keep another type of
> > source distribution).  Note that these files are only needed for
> > further development of the package, but *not* to install the package
> > from source (since their contents is already incorporated in the Rd
> > files).  They are also not of interest to the end-user.
>
> Henrik,
>
> I am not sure I fully understand the issue.
>
> The
>
>Note that these files are only needed for further development of the
>package
>
> suggests that these files are only needed for your local master sources,
> but not in the source package created by R CMD build.  If this is the
> case, then you really don't have to do anything, because R CMD build
> will happily exclude these files, and R CMD check on the .tar.gz will no
> longer find them.

Yes.  However, I would like to avoid to keep a version of "local
master sources".  Until now, all necessary code in my packages are
available in the *.tar.gz files build by R CMD build.  This is
convenient if someone else wants to contribute/add to my package, the
*.tar.gz is all that is needed and it is available on the web.  I can
also update my package on request, say, when I travel, without having
access to my "local master sources".  Kind of a poor man's
subversion/cvs.

Thanks

Henrik

> Best
> -k
>
> > My question is how to incorporate the *.Rex files?  Here are some
> > ideas, that I would like to have some feedback on:
>
> > 1) Put them in /R/Rex/*.Rex.  However, Section 1.1.4 in Writing R
> > Extensions suggest that subdirectories of R/ may only(?) be named
> > 'windows' or 'unix'.
>
> > 2) Rename them to /R/*.in, cf. Section 1.1.4.  Is this the
> > purpose of *.in files?  Will it have side effects?
>
> > 3) Put the in /inst//*.Rex.  This will work, but then they
> > will also be install and available in system.file("",
> > package="").  Not a big problem, but not what I want.
>
> > 4) To avoid (3), put the in //*.Rex, i.e. at the top level
> > directory.  Is this allowed?  Section 1.1.4 says "Note that [...]
> > information files at the top level of the package will not be
> > installed". Does this mean that they will be included in the source
> > distribution and what about top level directories?
>
> > 5) Put the in /src/*.Rex.  Can src/ be used this way too?
>
> > 6) Ask R-core to revert back to pre-R v2.3.0 and allow other files in
> > the R/ directory too.  Are more people than I interested in this?
>
> > I realize I can test the above by trial and error, but I will still
> > not be sure what is the right approach here.  Comments/feedback is
> > appreciated.
>
> > Thanks
>
> > Henrik
>
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
>


--
Henrik Bengtsson
Mobile: +46 708 909208 (+1h UTC)

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] ATLAS threaded 64 bit Opteron build for R: need -fPIC

[Prof Brian Ripley]

On Fri, 10 Feb 2006, Amit Aronovitch wrote:

You set the reply address to Martin Maechler!  That's antisocial.

> Hi,
>
> Sorry for sending such a late reply, and for being abit OT.
>
>  I've been trying to compile 64 bit ATLAS for numpy 
> (http://numeric.scipy.org/ ), and so far this thread is the most useful 
> one I could google up - thanks!.
>  I encountered similiar problems, and so far could not get a .a linkable 
> to numpy (comparing to your post - it seems I might have forgotten to 
> add the -fPIC for the F77FLAGS or MMFLAGS).

Yes, that _is_ in the R-admin manual.  I guess you have not read that - it 
describes how to install R.  You can get it in the R tarball from

ftp://ftp.stat.math.ethz.ch/Software/R/R-devel.tar.bz2


> Also, I'm having trouble with the ATLAS lapack. To get a usable lib, one 
> has to merge it with a full lapack implementation (as described in the 
> ATLAS errata). However, I'm using RHEL4, and their installed liblapack.a 
> seems to have been compiled without -fPIC, so the merged library is 
> unlinkable to numpy's .so. Is there a way to use Redhat's installed 
> liblapack.so?

No, nor should you want to.  If RHEL4 is like FC3/4 watch out, as RH have 
managed to get BLAS routines in liblapack and not liblas, and use 
incorrect patches to LAPACK 3.0.  (Again, see the latest R-admin manual.)

> Few questions about your compiler flags:
>
> 1) Is there a reason to compile with -O rather than -O3?
> (did you try and encounter some problem, or found no major performance
> difference)

ATLAS chose that.  Since the real work is done by hand-tuned assembler 
code it should not matter.

> 2) I see you use -mfpmath=387 - does this work better than sse2 (which
> seems to be
> the default)? How about the "sse,387" option - should I try that?

Depends on your ATLAS version.  Again, ATLAS chose those.

As it happens, I have been trying to build ATLAS on my new dual Opteron 
box this morning.  The latest devel version (3.7.11) does not build, as at 
some point it says it expects the GNU x86-32 assembler.  If it did it 
would use SSE3 and so be faster.

Both 3.6.0 and 3.7.11 fail because my machine is too fast, and I had to 
increase the number of replications (1000) in make/Make.{mv,r1}tune and in 
tune/blas/level1/*.c.  Even then I do not entirely trust the results (and 
the two versions report different L1 caches sizes ...).

I got pretty exasperated with this (it needed about ten builds to get one 
that succeeded).  Both ACML and the Goto BLAS work well out of the box on 
Opterons, but do have licence issues. (Again, see the R-admin manual for 
details.)


> Martin Maechler wrote:
>
>> / "PD" == Peter Dalgaard > >
> />/  >> "PD" == Peter Dalgaard 
>>> on 26 Feb 2004 15:44:16 +0100 writes:
>>
>>PD> Douglas Bates  writes:
>>   >> Have you tried configuring R with Goto's BLAS
>>   >> http://www.cs.utexas.edu/users/kgoto/
>>   >>
>>   >> I haven't worked with Opteron or Athlon64 computers but I understand
>>   >> that Goto's BLAS are very effective on those machines.  Furthermore
>>   >> Goto's BLAS are (only) available as .so libraries so you don't need to
>>   >> mess with creating the .so version.
>>
>>PD> I tried it, yes. Somewhat to my surprise, it seemed to be not quite as
>>PD> fast as the threaded ATLAS, but I wasn't very systematic about the
>>PD> benchmarking.
>>
>>PD> (and the Goto items have license issues, which get in the way for
>>PD> binary distributions.)
>>
>> Thanks a lot, Peter, Brian, Doug, for your feedbacks!
>> In the mean time, I have three running versions of R(-devel) on
>> the 64-Opteron
>> - "plain"
>> - linked against threaded GOTO
>> - linked against threaded (static) ATLAS  (using -fPIC for compilation;
>> "large" Rlapack)
>> and I find that GOTO is faster than ATLAS
>> consistently (between ~ 5-20%) for several tests
>> (square matrices; %*% and solve).
>> ATLAS is still an order of magnitude faster than "plain" for
>> 3000x3000 matrices.
>>
>> Here are somewhat repeatable "ATLAS for R" build instructions:
>>
>> 1. get ATLAS source; unpack
>> 2. make : use defaults and "express" installation
>> 3. Before "make install ...", edit the  Make. file:
>>add "-fPIC" to three places, namely  F77FLAGS, CCFLAG0, and MMFLAGS:
>>which in case of the "threaded Opteron" architecture, leads to
>>the three new lines
>>   F77FLAGS = -fPIC -fomit-frame-pointer -O -m64
>>
>>  CCFLAG0 = -fPIC -fomit-frame-pointer -O -mfpmath=387 -m64
>>
>>  MMFLAGS = -fPIC -fomit-frame-pointer -O -mfpmath=387 -m64
>>in the file   Make.Linux_HAMMER64SSE2_2
>>
>> 4. make install arch=Linux_HAMMER64SSE2_2
>>
>> 5. Sym.link the ATLAS libraries into /usr/local/lib:
>>
>>cd /usr/local/lib
>>ln -s /lib/Linux_HAMMER64SSE2_2/lib* .
>>
>> 6. (needed for runtime!):
>>Use environment variable LD_LIBRARY_PATH=/usr/local/lib
>

Re: [Rd] ?bquote

[Peter Dalgaard]

Gabor Grothendieck <[EMAIL PROTECTED]> writes:

> ?bquote says it returns an expression but, in fact, it typically
> (though not always) returns a call object:
> 
> > class(bquote(a+b))
> [1] "call"
> 
> > class(bquote(1))
> [1] "numeric"

Unevaluated expressions and objects of mode "expression" are not the
same thing. The latter is effectively a list wrapping one or more of
the former.

Unevaluated expressions are generally mode "call", except when they
are constants. They do, however, correspond to expressions as
syntactic element (look for "expr" inside gram.y in the sources). 

The terminology does not seem completely rationalised, see also the
help pages for expression() and substitute()/quote(), and it might be
worth cleaning it up at some point. Just requires someone with a
sufficiently clear mind to decide on issues like whether constants
qualify as "unevaluated calls"... (my hunch is that they don't, and
that "unevaluated expressions" should be used throughout, but my mind
is definitely not clear these days.)

Another question is whether it would be desirable for bquote to return
an "expression" object. I realized recently that 

> boxplot(rnorm(99),ylab=quote(a[1]))
Error in title(ylab = a[1]) : object "a" not found

and that you need expression(a[1]) instead. I think this implies that
you'd have to use as.expression(bquote()) which is a bit nasty.
I'm not sure this isn't a bug in boxplot, though.

-- 
   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
~~ - ([EMAIL PROTECTED])  FAX: (+45) 35327907

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] R CMD build: "Subdirectory 'R' contains invalid file names"

[Prof Brian Ripley]

On Fri, 10 Feb 2006, Henrik Bengtsson wrote:

> Hi,
>
> On 2/10/06, Kurt Hornik <[EMAIL PROTECTED]> wrote:
>>> Henrik Bengtsson writes:
>>
>>> Hi, I get
>>> * excluding invalid files from 'R.oo'
>>> Subdirectory 'R' contains invalid file names:
>>>   attachLocally.Object.Rex Exception.Rex extend.default.Rex
>>>   InternalErrorException.reportBug.Rex Package.Rex Person.Rex Rdoc.Rex
>>>   setMethodS3.Rex StaticFields.Rex
>>
>>> when running R CMD build in R v2.3.0 devel.  I do understand what is
>>> going on.  In my *.R files I keep so called Rdoc comments which in
>>> their simplest form are Rd code wrapped up in plain comments.  These
>>> are compiled into Rd files written to ../man/ (I do this prior to
>>> building packages).  Rdoc also supports inclusion of other files, e.g.
>>> @include "Person.Rex" to include example code.
>>
>>> With this structure I can, when I develop/maintain a package, have
>>> /R/ as the working directory, modify my *.R files and re-source
>>> them from within R.  Since I keep all my Rd example code in separate
>>> *.Rex files, I can easily rerun/test these by sourcing them too.  I
>>> find this very convenient.
>>
>>> In previous versions, the *.Rex files was included when building a
>>> source distribution of a package.  In R v2.3.0 they are excluded.
>>> However, I would like to distribute the *.Rex files with my
>>> source-code package too (so I do not have to keep another type of
>>> source distribution).  Note that these files are only needed for
>>> further development of the package, but *not* to install the package
>>> from source (since their contents is already incorporated in the Rd
>>> files).  They are also not of interest to the end-user.
>>
>> Henrik,
>>
>> I am not sure I fully understand the issue.
>>
>> The
>>
>>Note that these files are only needed for further development of the
>>package
>>
>> suggests that these files are only needed for your local master sources,
>> but not in the source package created by R CMD build.  If this is the
>> case, then you really don't have to do anything, because R CMD build
>> will happily exclude these files, and R CMD check on the .tar.gz will no
>> longer find them.
>
> Yes.  However, I would like to avoid to keep a version of "local
> master sources".  Until now, all necessary code in my packages are
> available in the *.tar.gz files build by R CMD build.  This is
> convenient if someone else wants to contribute/add to my package, the
> *.tar.gz is all that is needed and it is available on the web.  I can
> also update my package on request, say, when I travel, without having
> access to my "local master sources".  Kind of a poor man's
> subversion/cvs.

And inconvenient to everyone who has to pay to download your development 
files that they do not need.

Can you not put your master sources on your own web site.

>
> Thanks
>
> Henrik
>
>> Best
>> -k
>>
>>> My question is how to incorporate the *.Rex files?  Here are some
>>> ideas, that I would like to have some feedback on:
>>
>>> 1) Put them in /R/Rex/*.Rex.  However, Section 1.1.4 in Writing R
>>> Extensions suggest that subdirectories of R/ may only(?) be named
>>> 'windows' or 'unix'.
>>
>>> 2) Rename them to /R/*.in, cf. Section 1.1.4.  Is this the
>>> purpose of *.in files?  Will it have side effects?
>>
>>> 3) Put the in /inst//*.Rex.  This will work, but then they
>>> will also be install and available in system.file("",
>>> package="").  Not a big problem, but not what I want.
>>
>>> 4) To avoid (3), put the in //*.Rex, i.e. at the top level
>>> directory.  Is this allowed?  Section 1.1.4 says "Note that [...]
>>> information files at the top level of the package will not be
>>> installed". Does this mean that they will be included in the source
>>> distribution and what about top level directories?
>>
>>> 5) Put the in /src/*.Rex.  Can src/ be used this way too?
>>
>>> 6) Ask R-core to revert back to pre-R v2.3.0 and allow other files in
>>> the R/ directory too.  Are more people than I interested in this?
>>
>>> I realize I can test the above by trial and error, but I will still
>>> not be sure what is the right approach here.  Comments/feedback is
>>> appreciated.
>>
>>> Thanks
>>
>>> Henrik
>>
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
>
>
> --
> Henrik Bengtsson
> Mobile: +46 708 909208 (+1h UTC)
>
> __
> 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/mailma

[Rd] Accuracy of dnorm (PR#8586)

[marco . vezzoli]

Full_Name: Marco Vezzoli
Version: 2.2.0 2.1.0 2.0.0
OS: Solaris, Windows, Linux
Submission from: (NULL) (57.78.11.38)


The dnorm functions yield a wrong value when the standard deviation is near to
1e-1
e.g.
> dnorm(0,mean=0.04,sd=0.3)
[1] 1.318039

this error is consistent in various version and os.

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Accuracy of dnorm (PR#8586)

[Prof Brian Ripley]

On Fri, 10 Feb 2006, [EMAIL PROTECTED] wrote:

> Full_Name: Marco Vezzoli
> Version: 2.2.0 2.1.0 2.0.0
> OS: Solaris, Windows, Linux
> Submission from: (NULL) (57.78.11.38)
>
>
> The dnorm functions yield a wrong value when the standard deviation is near to
> 1e-1
> e.g.
>> dnorm(0,mean=0.04,sd=0.3)
> [1] 1.318039

What is wrong here?  Try the textbook formula

> x <- 0
> m <- 0.04
> sd <- 0.3
> 1/(sqrt(2*pi)*sd) * exp(-0.5*(x-m)^2/sd^2)
[1] 1.318039

> this error is consistent in various version and os.

It _is_ good that R is consistent.

I don't think we are going to believe you unless you give your credentials 
and state your `correct value' and your reasoning.

-- 
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] Accuracy of dnorm (PR#8586)

[Barry Rowlingson]

Prof Brian Ripley wrote:

>>The dnorm functions yield a wrong value when the standard deviation is near to
>>1e-1

> What is wrong here?  Try the textbook formula
> 
> 
>>x <- 0
>>m <- 0.04
>>sd <- 0.3
>>1/(sqrt(2*pi)*sd) * exp(-0.5*(x-m)^2/sd^2)
> 
> [1] 1.318039
> 

Even MS Excel gets this one right:

=NORMDIST(0,0.04,0.3,FALSE)

1.31803947

Barry

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Accuracy of dnorm (PR#8586)

[Peter Dalgaard]

[EMAIL PROTECTED] writes:

> Full_Name: Marco Vezzoli
> Version: 2.2.0 2.1.0 2.0.0
> OS: Solaris, Windows, Linux
> Submission from: (NULL) (57.78.11.38)
> 
> 
> The dnorm functions yield a wrong value when the standard deviation is near to
> 1e-1
> e.g.
> > dnorm(0,mean=0.04,sd=0.3)
> [1] 1.318039
> 
> this error is consistent in various version and os.

What's wrong with it???

> (pnorm(0.01,mean=0.04,sd=0.3) - pnorm(0,mean=0.04,sd=0.3))/.01
[1] 1.318040


-- 
   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
~~ - ([EMAIL PROTECTED])  FAX: (+45) 35327907

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Accuracy of dnorm (PR#8586)

[Marco VEZZOLI]

I'm very sorry for the error.
I confused probability density with the distribution.
Thank you for your answer.
Marco

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] ATLAS threaded 64 bit Opteron build for R: need -fPIC

[Amit Aronovitch]

Prof Brian Ripley wrote:

> On Fri, 10 Feb 2006, Amit Aronovitch wrote:
>
> You set the reply address to Martin Maechler!  That's antisocial.
>
Sincere apologies. I certainly didn't intend to!
(I probably misclicked while trying to put him on Cc: )

   Please ignore that header.

>> Hi,
>>
>> Sorry for sending such a late reply, and for being abit OT.
>>
>>  I've been trying to compile 64 bit ATLAS for numpy
>> (http://numeric.scipy.org/ ), and so far this thread is the most
>> useful one I could google up - thanks!.
>>  I encountered similiar problems, and so far could not get a .a
>> linkable to numpy (comparing to your post - it seems I might have
>> forgotten to add the -fPIC for the F77FLAGS or MMFLAGS).
>
>
> Yes, that _is_ in the R-admin manual.  I guess you have not read that
> - it describes how to install R.  You can get it in the R tarball from
>
> ftp://ftp.stat.math.ethz.ch/Software/R/R-devel.tar.bz2
>
>
>> Also, I'm having trouble with the ATLAS lapack. To get a usable lib,
>> one has to merge it with a full lapack implementation (as described
>> in the ATLAS errata). However, I'm using RHEL4, and their installed
>> liblapack.a seems to have been compiled without -fPIC, so the merged
>> library is unlinkable to numpy's .so. Is there a way to use Redhat's
>> installed liblapack.so?
>
>
> No, nor should you want to.  If RHEL4 is like FC3/4 watch out, as RH
> have managed to get BLAS routines in liblapack and not liblas, and use
> incorrect patches to LAPACK 3.0.  (Again, see the latest R-admin manual.)

Thanks for the tip - guess that means I'll have to compile my own lapack...

>
>> Few questions about your compiler flags:
>>
>> 1) Is there a reason to compile with -O rather than -O3?
>> (did you try and encounter some problem, or found no major performance
>> difference)
>
>
> ATLAS chose that.  Since the real work is done by hand-tuned assembler
> code it should not matter.
>
>> 2) I see you use -mfpmath=387 - does this work better than sse2 (which
>> seems to be
>> the default)? How about the "sse,387" option - should I try that?
>
>
> Depends on your ATLAS version.  Again, ATLAS chose those.
>
> As it happens, I have been trying to build ATLAS on my new dual
> Opteron box this morning.  The latest devel version (3.7.11) does not
> build, as at some point it says it expects the GNU x86-32 assembler. 
> If it did it would use SSE3 and so be faster.
>
> Both 3.6.0 and 3.7.11 fail because my machine is too fast, and I had
> to increase the number of replications (1000) in make/Make.{mv,r1}tune
> and in tune/blas/level1/*.c.  Even then I do not entirely trust the
> results (and the two versions report different L1 caches sizes ...).
>
> I got pretty exasperated with this (it needed about ten builds to get
> one that succeeded).  Both ACML and the Goto BLAS work well out of the
> box on Opterons, but do have licence issues. (Again, see the R-admin
> manual for details.)
>
I'll certainly have to read the R-admin manual.
Once I manage to get a working lib I'll try posting some of that info to
ATLAS lists (should prbly be included in atlas errata or something).

  thanks alot,
  Amit A.

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] invalid graphics state using dev.print (fwd)

[Martin Maechler]

> "Paul" == Paul Roebuck <[EMAIL PROTECTED]>
> on Wed, 8 Feb 2006 15:33:11 -0600 (CST) writes:

Paul> On Mon, 6 Feb 2006 18:12, Simon Urbanek wrote:
>> On Feb 6, 2006, at 5:24 PM, Paul Roebuck wrote:
>> 
>>> Tried on R-Sig-Mac with no responses, but I need some kind
>>> of answer.
>>> [...]
>>> Does the following work on your system?
>> 
>> Interesting, no, it doesn't either. For png and pdf I use
>> Quartz + quartz.save (it produces much nicer results) so
>> I didn't really notice, but you're right. First I thought
>> those graphics state issues are specific to the Quartz
>> device, but you have proven that it's not. It's in fact
>> not even Mac-specific - I have just reproduced it on a
>> Linux box - that's why I'm moving this to R-devel.

Paul> It's been several workdays now with no responses. Could
Paul> someone try the last three lines of code and see if they
Paul> get the following error message?

>> x11()
>> plot(rnorm(10))
>> dev.print(png)

Paul> Error in dev.copy(device = function (filename = "Rplot%03d.png", 
width =
Paul> 480,  :
Paul> invalid graphics state

>> traceback()
Paul> 6: dev.copy(device = function (filename = "Rplot%03d.png", width = 
480,
Paul> height = 480, pointsize = 12, gamma = 1, colortype =
Paul> getOption("X11colortype"),
Paul> maxcubesize = 256, bg = "white", fonts = getOption("X11fonts"),
Paul> res = NA)
Paul> .Internal(X11(paste("png::", filename, sep = ""), width, height,
Paul> pointsize, gamma, colortype, maxcubesize, bg, bg, fonts,
Paul> res)), width = 6.98715785526809, height = 6.99452568428947)
Paul> 5: eval(expr, envir, enclos)
Paul> 4: eval(expr, p)
Paul> 3: eval.parent(oc)
Paul> 2: dev.off(eval.parent(oc))
Paul> 1: dev.print(png)

Paul> I noticed it on OS X, and Simon on Linux. 

Yes, I can confim getting the same.
Just on Linux though (as Simon)

I'd say this should make a ``nice little''  bug.report() 

Interestingly, replacing

dev.print(png)

by  dev.copy(png) ; dev.off()  

which is about equivalent,  *does* work and so is a workaround
to your problem.

Regards,
Martin

Paul> Other platforms?  WFM?

Paul> TIA

>> version
Paul> _
Paul> platform powerpc-apple-darwin7.9.0
Paul> arch powerpc
Paul> os   darwin7.9.0
Paul> system   powerpc, darwin7.9.0
Paul> status   Patched
Paul> major2
Paul> minor2.1
Paul> year 2006
Paul> month02
Paul> day  01
Paul> svn rev  37245
Paul> language R

Paul> --
Paul> SIGSIG -- signature too long (core dumped)

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Citation of R packages

[Friedrich . Leisch]

> On Fri, 10 Feb 2006 21:01:44 +1100,
> John Maindonald (JM) wrote:

[...]

  > Where there is a published paper or a book (such as MASS), or a
  > manual for which a url can be given, my decision was to include
  > that in the main list of references, but not to include references
  > there that were references to the package itself, which as you
  > suggest below can be a reference to the concatenated help pages.

The CITATION file of a package may contain as many entries as the
author wants, including both a reference to the help pages and to the
book (or whatever).


  > It seemed anyway useful to have a separate list of packages.  For
  > consistency, these were always references to the package, with a
  > cross-reference to any relevant document in the references to papers.

  >>> (2) Maybe the author field should be more nuanced, or
  >>> maybe ...
  >> 
  >> author fields of bibtex entries have a strict format (names separated
  >> by "and"), what do you mean by "more nuanced"?

  > Those named in the list of authors may be any combination of: the  
  > authors
  > of an R package, the authors of an original S version, the person or  
  > persons
  > responsible for an R port, the authors of the Fortran code, compiler 
  > (s), and
  > contributors of ideas.

  > For John Fox's car, citation() gives the following:
  >  author = {John Fox. I am grateful to Douglas Bates and David  
  > Firth and Michael Friendly and Gregor Gorjanc and Georges Monette and  
  > Henric Nilsson and Brian Ripley and Sanford Weisberg and and Achim  
  > Zeleis for various suggestions and contributions.},

  > For Rcmdr:
  >  author = {John Fox and with contributions from Michael Ash and  
  > Philippe Grosjean and Martin Maechler and Dan Putler and and Peter  
  > Wolf.},

  > For car, maybe John Fox should be identified as author.  For Rcmdr,  
  > maybe the other persons that are named should be added?

  > For leaps:
  >  author = {Thomas Lumley using Fortran code by Alan Miller},

  > It seems reasonable to cite Lumley and Miller as authors.  Should  
  > there be a note that identifies Miller as the contributor of the  
  > Fortran code?

  > Should the name(s) of porters (usually from S) be included as author 
  > (s)?  Or should their contribution be acknowledged in the note field?  
  > Or ...

  > Possibilities are to cite all those individuals as author, or to cite  
  > John Fox only,
  > with any combination of no additional information in the note field,  
  > or using the
  > note field to explain who did what.  The citation() function leaves  
  > it unclear who
  > are to be acknowledged as authors, and in fact


Umm, the problem there is not the citation() function, but that the
authors of all those packages obviously have not included a CITATION
file in their package which overrides the default (extracted from the
DESCRIPTION file).

E.g., package flexclust has DESCRIPTION

Package: flexclust
Version: 0.8-1
Date: 2006-01-11
Author: Friedrich Leisch, parts based on code by Evgenia Dimitriadou

but


R> citation("flexclust")

To cite package flexclust in publications use:

  Friedrich Leisch. A Toolbox for K-Centroids Cluster Analysis.
  Computational Statistics and Data Analysis, 2006. Accepted for
  publication.

A BibTeX entry for LaTeX users is

  @Article{,
author = {Friedrich Leisch},
title = {A Toolbox for K-Centroids Cluster Analysis},
journal = {Computational Statistics and Data Analysis},
year = {2006},
note = {Accepted for publication},
  }


because the CITATION file overrides the DESCRIPTION file. Writing a
CITATION file is of course also intended for those cases where a
proper reference cannot be auto-generated from the DESCRIPTION file.


  >>> (3) In compiling a list of packages, name order seems
  >>> preferable, and one wants the title first (achieved by
  >>> relocating the format.title field in the manual FUNCTION
  >>> in the .bst file
  >>> (4) manual seems not an ideal name for the class, if
  >>> there is no manual.
  >> 
  >> A package always has a "reference manual", the concatenated help pages
  >> certainly qualify as such and can be downloaded in PDF format from
  >> CRAN. The ISBN rules even allow to assign an ISBN number to the online
  >> help of a software package which also can serve as the ISBN number of
  >> the *software itself* (which we did for base R).

  > I'd prefer some consistency in the way that R packages are referenced.
  > Thus, if reference for one package is to the concatenated help pages,
  > do it that way for all of them.

But we recommend that package authors should (try to) get their work
into reviewed journals like JSS, JCGS, or CSDA, and then package
authors usually prefer if the article gets cited. Unfortunately, many
academic institutions value paper publications higher than software.
Citing the help pages is mainly intended as a substitute if no journal
article is available.

Best,
Fritz

__

Re: [Rd] Citation of R packages

[John Maindonald]

Even if a CITATION file is included, there is an issue of what to put  
in it.
Authorship of a book or paper is not always the simple matter that might
appear.  With an R package, it can be a far from simple matter.  We are
trying to adapt a tool, surely, that was designed for different  
purposes.

1. I'd like to see the definition of a new BibTeX entry type that has  
fields for
additional author details and version number. There is surely some
mechanism for getting agreement on a new entry type.

2. In any case, there's a message for maintainers of packages to include
CITATION files that reflect what they want to appear in any citation,  
with
citation("lattice") as maybe a suitable model?

John.

John Maindonald email: [EMAIL PROTECTED]
phone : +61 2 (6125)3473fax  : +61 2(6125)5549
Mathematical Sciences Institute, Room 1194,
John Dedman Mathematical Sciences Building (Building 27)
Australian National University, Canberra ACT 0200.


On 11 Feb 2006, at 5:36 AM, [EMAIL PROTECTED] wrote:

>> On Fri, 10 Feb 2006 21:01:44 +1100,
>> John Maindonald (JM) wrote:
>
> [...]
>
>> Where there is a published paper or a book (such as MASS), or a
>> manual for which a url can be given, my decision was to include
>> that in the main list of references, but not to include references
>> there that were references to the package itself, which as you
>> suggest below can be a reference to the concatenated help pages.
>
> The CITATION file of a package may contain as many entries as the
> author wants, including both a reference to the help pages and to the
> book (or whatever).
>
>
>> It seemed anyway useful to have a separate list of packages.  For
>> consistency, these were always references to the package, with a
>> cross-reference to any relevant document in the references to papers.
>
 (2) Maybe the author field should be more nuanced, or
 maybe ...
>>>
>>> author fields of bibtex entries have a strict format (names  
>>> separated
>>> by "and"), what do you mean by "more nuanced"?
>
>> Those named in the list of authors may be any combination of: the
>> authors
>> of an R package, the authors of an original S version, the person or
>> persons
>> responsible for an R port, the authors of the Fortran code, compiler
>> (s), and
>> contributors of ideas.
>
>> For John Fox's car, citation() gives the following:
>>  author = {John Fox. I am grateful to Douglas Bates and David
>> Firth and Michael Friendly and Gregor Gorjanc and Georges Monette and
>> Henric Nilsson and Brian Ripley and Sanford Weisberg and and Achim
>> Zeleis for various suggestions and contributions.},
>
>> For Rcmdr:
>>  author = {John Fox and with contributions from Michael Ash and
>> Philippe Grosjean and Martin Maechler and Dan Putler and and Peter
>> Wolf.},
>
>> For car, maybe John Fox should be identified as author.  For Rcmdr,
>> maybe the other persons that are named should be added?
>
>> For leaps:
>>  author = {Thomas Lumley using Fortran code by Alan Miller},
>
>> It seems reasonable to cite Lumley and Miller as authors.  Should
>> there be a note that identifies Miller as the contributor of the
>> Fortran code?
>
>> Should the name(s) of porters (usually from S) be included as author
>> (s)?  Or should their contribution be acknowledged in the note field?
>> Or ...
>
>> Possibilities are to cite all those individuals as author, or to cite
>> John Fox only,
>> with any combination of no additional information in the note field,
>> or using the
>> note field to explain who did what.  The citation() function leaves
>> it unclear who
>> are to be acknowledged as authors, and in fact
>
>
> Umm, the problem there is not the citation() function, but that the
> authors of all those packages obviously have not included a CITATION
> file in their package which overrides the default (extracted from the
> DESCRIPTION file).
>
> E.g., package flexclust has DESCRIPTION
>
> Package: flexclust
> Version: 0.8-1
> Date: 2006-01-11
> Author: Friedrich Leisch, parts based on code by Evgenia Dimitriadou
>
> but
>
> 
> R> citation("flexclust")
>
> To cite package flexclust in publications use:
>
>   Friedrich Leisch. A Toolbox for K-Centroids Cluster Analysis.
>   Computational Statistics and Data Analysis, 2006. Accepted for
>   publication.
>
> A BibTeX entry for LaTeX users is
>
>   @Article{,
> author = {Friedrich Leisch},
> title = {A Toolbox for K-Centroids Cluster Analysis},
> journal = {Computational Statistics and Data Analysis},
> year = {2006},
> note = {Accepted for publication},
>   }
> 
>
> because the CITATION file overrides the DESCRIPTION file. Writing a
> CITATION file is of course also intended for those cases where a
> proper reference cannot be auto-generated from the DESCRIPTION file.
>
>
 (3) In compiling a list of packages, name order seems
 preferable, and one wants the title first (achieved by
 relocating the format.title field in the manual FUNCTION
>>>

[Rd] Arguments of 'transform'

[Bill.Venables]

If you would like a 10 second R puzzle, you might like to think about
this one:


> g <- expand.grid(long = 130:140, lat = -(10:25))
> gp <- transform(g, x = long, y = lat)
Error in transform(g, x = long, y = lat) : 
object "long" not found


I don't expect this hasn't come up before, but I can't find mention of
it.  I suggest that to minimise this little stumbling block for
beginners (and others) we either

change the name of the principal argument in transform from 'x'
to, say '.x' (or even 'data' as it is in 'with' for example)  OR

at least put a note in the help file for 'transform' in the
'Detalis' section to say
 
*** NOTE: The only tag name unavailable to be used is 'x'. ***

Just another little seed.

Bill.

Bill Venables, 
CMIS, CSIRO Laboratories, 
PO Box 120, Cleveland, Qld. 4163 
AUSTRALIA 
Office Phone (email preferred): +61 7 3826 7251 
Fax (if absolutely necessary):+61 7 3826 7304 
Mobile (rarely used):+61 4 1963 4642 
Home Phone:  +61 7 3286 7700 
mailto:[EMAIL PROTECTED] 
http://www.cmis.csiro.au/bill.venables/

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] ?bquote

[Gabor Grothendieck]

On 10 Feb 2006 12:15:10 +0100, Peter Dalgaard <[EMAIL PROTECTED]> wrote:
> Gabor Grothendieck <[EMAIL PROTECTED]> writes:
>
> > ?bquote says it returns an expression but, in fact, it typically
> > (though not always) returns a call object:
> >
> > > class(bquote(a+b))
> > [1] "call"
> >
> > > class(bquote(1))
> > [1] "numeric"
>
> Unevaluated expressions and objects of mode "expression" are not the
> same thing. The latter is effectively a list wrapping one or more of
> the former.
>
> Unevaluated expressions are generally mode "call", except when they
> are constants. They do, however, correspond to expressions as
> syntactic element (look for "expr" inside gram.y in the sources).
>
> The terminology does not seem completely rationalised, see also the
> help pages for expression() and substitute()/quote(), and it might be
> worth cleaning it up at some point. Just requires someone with a
> sufficiently clear mind to decide on issues like whether constants
> qualify as "unevaluated calls"... (my hunch is that they don't, and
> that "unevaluated expressions" should be used throughout, but my mind
> is definitely not clear these days.)
>
> Another question is whether it would be desirable for bquote to return
> an "expression" object. I realized recently that
>
> > boxplot(rnorm(99),ylab=quote(a[1]))
> Error in title(ylab = a[1]) : object "a" not found
>
> and that you need expression(a[1]) instead. I think this implies that
> you'd have to use as.expression(bquote()) which is a bit nasty.
> I'm not sure this isn't a bug in boxplot, though.

I think this is the same issue that Berton Gunter brought up on r-help
recently with

   x <- y <- 1:10
   plot(y ~ x, main=quote(abc))

which gives an error message even though

   plot(x,y,main=quote(abc))

does not.

The first case seems to be stripping off one layer so that

   plot(y ~ x, quote(quote(abc)))

is ok but just one quote is not.

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel