Re: [Rd] Citation for R
> On Tue, 14 Jun 2005 10:38:38 +1000,
> Gordon Smyth (GS) wrote:
>> Note also that R does have a User Guide, i.e., while there is plenty of
>> excellent documentation,
>> there is no single document which is a guide to the whole project.
> Oops, I meant to write "R does not have a User Guide".
> Just to explain this further, the citation() function asks me to cite a
> "Manual" with the title "R: A language and environment for statistical
> computing". Although R comes with excellent documentation, including at
> least 6 manuals on different aspects of the software, no manual or document
> with that title actually exists, as far as I know.
The Reference Index (all help Pages in one PDF document) has that name
("Reference Index" is actually the subtitle), and you can download it
from
http://cran.r-project.org/manuals.html
(it's the 12MB guy at the end of the list of manuals). The ISBN rules
make it possible to cover both a software package and it's
corresponding reference manual by one single ISBN number if they are
bundled tightly and that's what we did for R. So as far as citations
go this should be as good a reference as any printed book. ISBN does not
require the item to be available for sale in printed form, electronic
publication is sufficient, see
http://www.isbn-international.org/en/userman/chapter6.html
The only open question is how many ISBN number we need exactly for R
(every patch release, every minor release etc.). I had a short
discussion with the Austrian ISBN representative and he recommended
for a fast-changing work like R to consider it like a database or
encyclopedia (which is true for the help pages anyway), and be rather
pragmatic. Hence we assigned a new ISBN to version 2.0.0 and will do so
again for 3.0.0.
Best,
--
---
Friedrich Leisch
Institut für Statistik Tel: (+43 1) 58801 10715
Technische Universität WienFax: (+43 1) 58801 10798
Wiedner Hauptstraße 8-10/1071
A-1040 Wien, Austria http://www.ci.tuwien.ac.at/~leisch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Citation for R
> On Tue, 14 Jun 2005 08:42:59 +1000 (EST), > Gordon K Smyth (GKS) wrote: > On Tue, June 14, 2005 12:49 am, Thomas Lumley said: >> On Mon, 13 Jun 2005, Gordon K Smyth wrote: >> >>> This is just a note that R would get a lot more citations if the >>> recommended citation was an article in a recognised journal or from a >>> recognised publisher. >>> >> >> This is unfortunately true, but R is *not* an article or a book, it is a >> piece of software. I don't think I'm the only person who thinks it is >> counterproductive in the long run to encourage users to cite an article >> that they probably haven't read instead of citing the software they >> actually used. >> >> Jan's suggestion of the Journal of Statistical Software might provide a >> solution, since JSS *does* publish software. >> >> -thomas > In the biology world, it is common to publish an article > announcing a software project, and to cite that. The referees of > the article are expected to try out and comment on the software. > This gives the authors credit, and ensures that both the article > and the software have been peer refereed, at least to a limited > extent. How do you cite books in this world, or to but the question in another way: How do you make sure a book is peer-reviewd? After all it is quite easy to become a "publisher" and publish ones own books. Many university departments I know are registered ISBN publishers (including our department). Must be hard to distinguish "real" books from others, I guess. Fritz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] operators as S4 methods
Dear all, I need to re-define some mathematical operators (+, *, /, etc) for an S4 class based on array. All references I have found (S Programming, Green Book) show how to define S3 methods for this (like in page 89 of S Programming for "-.polynomial"). What is the preferred S4 way for doing this? I hope I haven't missed some obvious piece of documentation. Many thanks, Iago Mosqueira __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Citation for R
On 6/14/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > On Tue, 14 Jun 2005 08:42:59 +1000 (EST), > > Gordon K Smyth (GKS) wrote: > > > On Tue, June 14, 2005 12:49 am, Thomas Lumley said: > >> On Mon, 13 Jun 2005, Gordon K Smyth wrote: > >> > >>> This is just a note that R would get a lot more citations if the > >>> recommended citation was an article in a recognised journal or from a > >>> recognised publisher. > >>> > >> > >> This is unfortunately true, but R is *not* an article or a book, it is a > >> piece of software. I don't think I'm the only person who thinks it is > >> counterproductive in the long run to encourage users to cite an article > >> that they probably haven't read instead of citing the software they > >> actually used. > >> > >> Jan's suggestion of the Journal of Statistical Software might provide a > >> solution, since JSS *does* publish software. > >> > >> -thomas > > > In the biology world, it is common to publish an article > > announcing a software project, and to cite that. The referees of > > the article are expected to try out and comment on the software. > > This gives the authors credit, and ensures that both the article > > and the software have been peer refereed, at least to a limited > > extent. > > How do you cite books in this world, or to but the question in another > way: How do you make sure a book is peer-reviewd? After all it is > quite easy to become a "publisher" and publish ones own books. Many > university departments I know are registered ISBN publishers > (including our department). Must be hard to distinguish "real" books > from others, I guess. Fritz - That's silly. As someone pointed out, the issue is with the publisher, not the citation. If R-Core were a generally well-known and regarded publishing house such as Springer or Microsoft, it would not be a problem. But it's still a nebulous entity to MANY people, and so many people fail to understand this open source stuff. It's seriously discouraged by most journals to cite technical reports, for example. And perhaps, R could be considered more of a long-ish technical report than a book? Though perhaps Peter D. could be considered the "editor"? (these questions are not those that I need to ask, obviously!) (just yesterday, I was asked by a reasonably intelligent colleague, with respect to corporate packaging of R: "So they (corporate packagers) just pick some version and package it, right?" and my flabbergasted response was: "and so, what the heck do you think they (corporate packagers) do with SAS, S-PLUS, and SPSS, and why do you think it's different...?"). best, -tony "Commit early,commit often, and commit in a repository from which we can easily roll-back your mistakes" (AJR, 4Jan05). A.J. Rossini [EMAIL PROTECTED] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] operators as S4 methods
For arithmetic operators,
the most elegant way often is to define so called `group methods'
for the whole group of arithmetic operators.
This actually applies also applies to the old classes and
methods.
One example where we do this is the 'Matrix' package,
see the source, e.g., in
https://svn.r-project.org/R-packages/Matrix/R/dMatrix.R
Note that for a namespaced package, on also needs to import the
group generics from the 'methods' package in NAMESPACE:
## Currently, group generics need to be explicitly imported:
importFrom("methods", Arith, Compare, Math, Math2, Summary, Complex)
Martin Maechler, ETH Zurich
> "Iago" == Iago Mosqueira <[EMAIL PROTECTED]>
> on Tue, 14 Jun 2005 09:23:40 +0200 writes:
Iago> Dear all,
Iago> I need to re-define some mathematical operators (+, *, /, etc) for an
S4
Iago> class based on array. All references I have found (S Programming,
Green
Iago> Book) show how to define S3 methods for this (like in page 89 of S
Iago> Programming for "-.polynomial"). What is the preferred S4 way for
doing
Iago> this? I hope I haven't missed some obvious piece of documentation.
Iago> Many thanks,
Iago> Iago Mosqueira
Iago> __
Iago> R-devel@r-project.org mailing list
Iago> 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] Citation for R
At 05:22 PM 14/06/2005, [EMAIL PROTECTED] wrote: > > On Tue, 14 Jun 2005 08:42:59 +1000 (EST), > > Gordon K Smyth (GKS) wrote: > > > On Tue, June 14, 2005 12:49 am, Thomas Lumley said: > >> On Mon, 13 Jun 2005, Gordon K Smyth wrote: > >> > >>> This is just a note that R would get a lot more citations if the > >>> recommended citation was an article in a recognised journal or from a > >>> recognised publisher. > >>> > >> > >> This is unfortunately true, but R is *not* an article or a book, it is a > >> piece of software. I don't think I'm the only person who thinks it is > >> counterproductive in the long run to encourage users to cite an article > >> that they probably haven't read instead of citing the software they > >> actually used. > >> > >> Jan's suggestion of the Journal of Statistical Software might provide a > >> solution, since JSS *does* publish software. > >> > >> -thomas > > > In the biology world, it is common to publish an article > > announcing a software project, and to cite that. The referees of > > the article are expected to try out and comment on the software. > > This gives the authors credit, and ensures that both the article > > and the software have been peer refereed, at least to a limited > > extent. > >How do you cite books in this world, or to but the question in another >way: How do you make sure a book is peer-reviewd? After all it is >quite easy to become a "publisher" and publish ones own books. Many >university departments I know are registered ISBN publishers >(including our department). Must be hard to distinguish "real" books >from others, I guess. > >Fritz Books are cited as in the statistics literature but, naturally, there is a tendency to prefer references from more reputable sources. Hence a Wiley & Son book would be prefered, other things being equal, to a book from a minor university press, which is turn would be prefered to a self-published book. Self-published electronic books are pretty much at the bottom of the pile. This doesn't mean that important references of this form can't be cited, but it doesn mean that one is pushing uphill. Self-published software manuals are usually cited in-text, as are many other tools and technologies mentioned in the methods section, rather than in the references. Thanks for pointing out, in a separate posting, that citation() refers to the "R Reference Manual". Gordon __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Citation for R
On 14-Jun-05 A.J. Rossini wrote: > Fritz - > > That's silly. As someone pointed out, the issue is with the > publisher, not the citation. If R-Core were a generally well-known > and regarded publishing house such as Springer or Microsoft, it would > not be a problem. But it's still a nebulous entity to MANY people, > and so many people fail to understand this open source stuff. It's > seriously discouraged by most journals to cite technical reports, for > example. And perhaps, R could be considered more of a long-ish > technical report than a book? Though perhaps Peter D. could be > considered the "editor"? (these questions are not those that I need > to ask, obviously!) > > (just yesterday, I was asked by a reasonably intelligent colleague, > with respect to corporate packaging of R: "So they (corporate > packagers) just pick some version and package it, right?" and my > flabbergasted response was: > > "and so, what the heck do you think they (corporate packagers) do with > SAS, S-PLUS, and SPSS, and why do you think it's different...?"). > > best, > -tony Tony is getting admirably and justifiably tetchy! His comment about the packaging of SAS, S-PLUS and SPSS is delightfully to the point (and, had I been there at the time, I'd have bought him a beverage of his choice in appreciation). And, to extend his comment, where for instance does that leave WinBUGS (see my previous mail)? Granted, perhaps, that in the citation Spiegelhalter, D. J., Thomas, A. and Best, N. G. (2000) WinBUGS Version 1.3 User Manual. Cambridge: Medical Research Council Biostatistics Unit. (Available from www.mrc-bsu.cam.ac.uk/bugs.) one has a prestigious institute (MRC-BSU) as the publisher. But, basically, it's the same self-justifiying ordinance all over again: the creators of the software produce their own User Manual and "publish" it. The publisher of S-PLUS and its documentation is "Insightful Corporation": beyond their achievement in developing S-PLUS, whence their prestige? (Granted, again, if you look inside the books, you can find famous names listed as contributors; but we at R can claim many of these same names ... ). The issue of "peer review" of software citations has been raised. Where is the peer review of the S-PLUS or SAS or SPSS User Manual? OK, the thing that needs peer review is the software itself. In the "Review" section of journals you can find critical reviews of software. But these are not referee'd and usually represent the writer's own views; furthermore, such reviews are not often cited in articles where the software has been used to obtain the results in the article. People just use the stuff, and cite the User Manual or the "corporate packager". Also, from time to time you come across published referee'd articles which analyse the performance of software for particular purposes, or compare different software packages for a given purpose. These could be viewed as peer review, but, again, are rarely cited by the simple user. Moreover, suppose that citing User Manual or corporate packager is considered to justify the use of the software in an article. I have seen many articles where such-and-such software was used (I mention no names) and "cited" in these terms, where it is known to discerning users that the software does not correctly address the tasks it claims to work for, or gives incorrect results. Yet the "citation box" had been duly ticked, and the article has successfully gone through the editorial process. This is not peer review either -- and could only come close to it if the journal editors' panel of referees could be assumed sufficiently knowledgeable to be discriminating about such things. But in that case you don't really need a citation: the referee says "Used [e.g.] S-PLUS, yes, that's fine for this job and I could reproduce the analysis using that software and trust the results. Passed." And such a referee could say exactly the same for R. The true peer review of software is done by discriminating users of the software. Peer review of R is done *HERE* (as well as other places). [I've had the experience of using R for analysis, only to have the analysis repeated in S-PLUS purely for the purpose of citing S-PLUS rather than R for publication ... ] However, the follow-ups in this thread are departing somewhat from Gordon Smyth's original wish to pay tribute, in citation, to the growing team of people who have, over the last 10+ years, contributed centrally to making R what it is. Thinking about that question, I can't come up with a better idea than his: an up-to-date "Ihaka and Gentleman", which does due honour to the greatly enhanced riches of R, and R's solidity and quality, at the present time! But maybe this might take a book ... Best wishes to all, Ted. E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 14-Jun-05
[Rd] by should use match.fun (PR#7936)
Full_Name: G. Grothendieck
Version: R version 2.1.0, 2005-06-10
OS: Windows XP
Submission from: (NULL) (216.59.226.184)
This is an inconsistency between by and similar functions.
The 'by' function should have an initial line of:
FUN <- match.fun(FUN)
All other similar functions including apply, sapply,
tapply, lapply work like that so 'by' ought to as well.
Here is an example using the 'iris' data set. Suppose we
wish to create a list of rows:
by(iris, row.names(iris), "(")
In every other similar function "(" would have been interpreted
as the intended function but here we get an error that it cannot
find "(". Although such an error is not inconsistent with the
documentation it would seem to violate the consistency of the
R base functions mentioned.
There was a discussion of this on r-devel in this thread:
https://www.stat.math.ethz.ch/pipermail/r-devel/2005-June/033583.html
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Calling C from Fortran
I would like to call C routines from Fortran under linux as suggested in
section 5.6 of
the "Writing R extensions" documentation.
I'm familiar with Fortran but not with C.
I understand the example provided in Fortran:
subroutine testit()
double precision normrnd, x
call rndstart()
x = normrnd()
call dblepr("X was", 5, x, 1)
call rndend()
end
but I don't understand the purpose of this C wrapper:
#include
void F77_SUB(rndstart)(void) { GetRNGstate(); }
void F77_SUB(rndend)(void) { PutRNGstate(); }
double F77_SUB(normrnd)(void) { return norm_rand(); }
neither how I should compile it.
Could anyone explain how I should compile and link
the C and Fortran files above, and call the Fortran subroutine from R.
Thanks,
Gilles
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Calling C from Fortran
The C wrappers are there to align the linking conventions expected by the
Fortran compiler (usually subroutine/function foo has its entry point in the
object file indicated by a symbol foo_, but it depends on the platform) to
that of the C compiler. (The C compiler just uses the function name.) The
wrappers give C functions named whatever is appropriate (eg "foo_") to get
an entry point that "call foo" will trigger linking to.
Calling the Fortran subroutine from R is via .Fortran() after doing a
dyn.load() of the shared object file. Creating the shared object should just
be a matter of R CMD SHLIB file1.c file2.f but I've never tried using
Fortran and C together. Take a look at the magic built in to the R CMD SHLIB
and R CMD COMPILE commands, and at some of the packages that come with R (I
just do a "find" for "*.f" in the src tree) if you need examples, eg.
src/library/stats.
Reid Huntsinger
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Gilles GUILLOT
Sent: Tuesday, June 14, 2005 1:05 PM
To: R-devel@stat.math.ethz.ch
Subject: [Rd] Calling C from Fortran
I would like to call C routines from Fortran under linux as suggested in
section 5.6 of
the "Writing R extensions" documentation.
I'm familiar with Fortran but not with C.
I understand the example provided in Fortran:
subroutine testit()
double precision normrnd, x
call rndstart()
x = normrnd()
call dblepr("X was", 5, x, 1)
call rndend()
end
but I don't understand the purpose of this C wrapper:
#include
void F77_SUB(rndstart)(void) { GetRNGstate(); }
void F77_SUB(rndend)(void) { PutRNGstate(); }
double F77_SUB(normrnd)(void) { return norm_rand(); }
neither how I should compile it.
Could anyone explain how I should compile and link
the C and Fortran files above, and call the Fortran subroutine from R.
Thanks,
Gilles
__
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 2.1.1 slated for June 20
On Fri, 2005-06-10 at 14:57 +0100, Prof Brian Ripley wrote:
> On Fri, 10 Jun 2005, Peter Dalgaard wrote:
>
> > The next version of R will be released (barring force majeure) on June
> > 20th, with beta versions available starting Monday.
> >
> > Please do check them on your system *before* the release this time...
>
> Some things which it would be particularly helpful to have tested:
> - Bleeding-edge OSes, e.g. anyone running Fedora Core 4 test 3? (These
>often show up problems with bugs in the pre-release versions of
>components such as X11 and compilers.)
Just as a quick heads up, I installed FC4 Release ("Stentz") late
yesterday.
R (Version 2.1.1 beta (2005-06-14)) compiles fine using:
$ gcc --version
gcc (GCC) 4.0.0 20050519 (Red Hat 4.0.0-8)
and make check-all passes with no problems.
I have also installed all CRAN packages that do not require other 3rd
party drivers, etc. and there were no observed errors in those cases.
So far, so good.
If anything comes up, I will post a follow up.
Best regards,
Marc Schwartz
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] wrong environment in anova call inside function (PR#7937)
Hi,
I am working with R version 2.1.0, and I seem to have run into a bug. I get
the same bug when I run R on Windows as well as when I run it on Linux.
When I call anova to do a LR test from inside a function, I get an error.
The same call works outside of a function. I have provided the code below.
Thanks,
Nisha Mulakken
myFunction <- function(myDataFrame) {
# Less restricted
fit1 <- gls(y ~ dose,
weights=varIdent(form=~1|dose),
data=myDataFrame)
# more restricted
fit2 <- gls(y ~ dose,
data=myDataFrame)
anova.results <- anova(fit1, fit2)
anova.results
}
df <- data.frame( y=c(12,3,45,1,53,6),
dose=c(0,10,200,0,10,200),
time=c("4.00 hrs", "4.00 hrs", "6.00 hrs", "6.00 hrs",
"8.00 hrs", "8.00 hrs"),
time.hours=c(4, 4, 6, 6, 8, 8),
rep=rep("a", 6)
)
## This leads to the following error:
## Error in anova.lme(object = fit1, fit2) : Object "fit2" not found
results <- myFunction(myDataFrame=df)
#
## The same thing outside of a function
# Less restricted
fit3 <- gls(y ~ dose,
weights=varIdent(form=~1|dose),
data=df)
# more restricted
fit4 <- gls(y ~ dose,
data=df)
## This works:
anova(fit3, fit4)
## The results:
## > anova(fit3, fit4)
## Model df AIC BIClogLik Test L.Ratio p-value
## fit3 1 5 57.98998 54.92145 -23.99499
## fit4 2 3 55.75284 53.91172 -24.87642 1 vs 2 1.76286 0.4142
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] wrong environment in anova call inside function (PR#7937)
anova() is a generic function in R, and not implicated here: do read the
error message which pinpoints anova.lme, part of package nlme.
The FAQ asks only package maintainers to use R-bugs for contributed
packages such as nlme. Please do read it.
On Tue, 14 Jun 2005 [EMAIL PROTECTED] wrote:
> Hi,
>
> I am working with R version 2.1.0, and I seem to have run into a bug. I get
> the same bug when I run R on Windows as well as when I run it on Linux.
>
> When I call anova to do a LR test from inside a function, I get an error.
> The same call works outside of a function. I have provided the code below.
>
> Thanks,
> Nisha Mulakken
>
>
>
> myFunction <- function(myDataFrame) {
>
> # Less restricted
> fit1 <- gls(y ~ dose,
> weights=varIdent(form=~1|dose),
> data=myDataFrame)
>
> # more restricted
> fit2 <- gls(y ~ dose,
> data=myDataFrame)
>
> anova.results <- anova(fit1, fit2)
> anova.results
> }
>
> df <- data.frame( y=c(12,3,45,1,53,6),
> dose=c(0,10,200,0,10,200),
> time=c("4.00 hrs", "4.00 hrs", "6.00 hrs", "6.00 hrs",
> "8.00 hrs", "8.00 hrs"),
> time.hours=c(4, 4, 6, 6, 8, 8),
> rep=rep("a", 6)
> )
>
> ## This leads to the following error:
> ## Error in anova.lme(object = fit1, fit2) : Object "fit2" not found
> results <- myFunction(myDataFrame=df)
>
> #
> ## The same thing outside of a function
>
> # Less restricted
> fit3 <- gls(y ~ dose,
> weights=varIdent(form=~1|dose),
> data=df)
>
> # more restricted
> fit4 <- gls(y ~ dose,
> data=df)
>
> ## This works:
> anova(fit3, fit4)
>
> ## The results:
> ## > anova(fit3, fit4)
> ## Model df AIC BIClogLik Test L.Ratio p-value
> ## fit3 1 5 57.98998 54.92145 -23.99499
> ## fit4 2 3 55.75284 53.91172 -24.87642 1 vs 2 1.76286 0.4142
--
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] R 2.1.1 slated for June 20
Marc,
Thanks for the confirmation. Is this using gfortran too? A date of
20050519 should be after the show-stopper bug was fixed, but I am waiting
for 4.0.1 to be released (imminent) before doing more tests with gcc4.
Brian
On Tue, 14 Jun 2005, Marc Schwartz wrote:
> On Fri, 2005-06-10 at 14:57 +0100, Prof Brian Ripley wrote:
>> On Fri, 10 Jun 2005, Peter Dalgaard wrote:
>>
>>> The next version of R will be released (barring force majeure) on June
>>> 20th, with beta versions available starting Monday.
>>>
>>> Please do check them on your system *before* the release this time...
>>
>> Some things which it would be particularly helpful to have tested:
>
>
>> - Bleeding-edge OSes, e.g. anyone running Fedora Core 4 test 3? (These
>>often show up problems with bugs in the pre-release versions of
>>components such as X11 and compilers.)
>
>
> Just as a quick heads up, I installed FC4 Release ("Stentz") late
> yesterday.
>
> R (Version 2.1.1 beta (2005-06-14)) compiles fine using:
>
> $ gcc --version
> gcc (GCC) 4.0.0 20050519 (Red Hat 4.0.0-8)
>
> and make check-all passes with no problems.
>
> I have also installed all CRAN packages that do not require other 3rd
> party drivers, etc. and there were no observed errors in those cases.
>
> So far, so good.
>
> If anything comes up, I will post a follow up.
>
> Best regards,
>
> Marc Schwartz
>
>
>
--
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] R 2.1.1 slated for June 20
Prof. Ripley,
If my read of the config.log is correct, it would appear that g77 was
used and not gfortran (which is installed):
...
C compiler:gcc -g -O2
C++ compiler: g++ -g -O2
Fortran compiler: g77 -g -O2
...
$ g77 --version
GNU Fortran (GCC 3.2.3 20030502 (Red Hat Linux 3.2.3-47.fc4)) 3.2.3
20030502 (Red Hat Linux 3.2.3-13)
$ gfortran --version
GNU Fortran 95 (GCC 4.0.0 20050519 (Red Hat 4.0.0-8))
Checking 'man gfortran':
Gfortran is not yet a fully conformant Fortran 95 compiler. It can
generate code for most constructs and expressions, but work remains to
be done. In particular, there are known deficiencies with ENTRY,
NAMELIST, and sophisticated use of MODULES, POINTERS and DERIVED TYPES.
For those whose Fortran codes conform to either the Fortran 77 standard
or the GNU Fortran 77 language, we recommend to use g77 from GCC 3.4.
We recommend that distributors continue to provide packages of g77-3.4
until we announce that gfortran fully replaces g77. The gfortran
developers welcome any feedback on user experience with gfortran at
<[EMAIL PROTECTED]>.
HTH,
Marc
On Tue, 2005-06-14 at 21:12 +0100, Prof Brian Ripley wrote:
> Marc,
>
> Thanks for the confirmation. Is this using gfortran too? A date of
> 20050519 should be after the show-stopper bug was fixed, but I am waiting
> for 4.0.1 to be released (imminent) before doing more tests with gcc4.
>
> Brian
>
> On Tue, 14 Jun 2005, Marc Schwartz wrote:
>
> > On Fri, 2005-06-10 at 14:57 +0100, Prof Brian Ripley wrote:
> >> On Fri, 10 Jun 2005, Peter Dalgaard wrote:
> >>
> >>> The next version of R will be released (barring force majeure) on June
> >>> 20th, with beta versions available starting Monday.
> >>>
> >>> Please do check them on your system *before* the release this time...
> >>
> >> Some things which it would be particularly helpful to have tested:
> >
> >
> >> - Bleeding-edge OSes, e.g. anyone running Fedora Core 4 test 3? (These
> >>often show up problems with bugs in the pre-release versions of
> >>components such as X11 and compilers.)
> >
> >
> > Just as a quick heads up, I installed FC4 Release ("Stentz") late
> > yesterday.
> >
> > R (Version 2.1.1 beta (2005-06-14)) compiles fine using:
> >
> > $ gcc --version
> > gcc (GCC) 4.0.0 20050519 (Red Hat 4.0.0-8)
> >
> > and make check-all passes with no problems.
> >
> > I have also installed all CRAN packages that do not require other 3rd
> > party drivers, etc. and there were no observed errors in those cases.
> >
> > So far, so good.
> >
> > If anything comes up, I will post a follow up.
> >
> > Best regards,
> >
> > Marc Schwartz
> >
> >
> >
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 2.1.1 slated for June 20
Marc Schwartz <[EMAIL PROTECTED]> writes:
> On Fri, 2005-06-10 at 14:57 +0100, Prof Brian Ripley wrote:
> > On Fri, 10 Jun 2005, Peter Dalgaard wrote:
> >
> > > The next version of R will be released (barring force majeure) on June
> > > 20th, with beta versions available starting Monday.
> > >
> > > Please do check them on your system *before* the release this time...
> >
> > Some things which it would be particularly helpful to have tested:
>
>
> > - Bleeding-edge OSes, e.g. anyone running Fedora Core 4 test 3? (These
> >often show up problems with bugs in the pre-release versions of
> >components such as X11 and compilers.)
>
>
> Just as a quick heads up, I installed FC4 Release ("Stentz") late
> yesterday.
>
> R (Version 2.1.1 beta (2005-06-14)) compiles fine using:
>
> $ gcc --version
> gcc (GCC) 4.0.0 20050519 (Red Hat 4.0.0-8)
>
> and make check-all passes with no problems.
>
> I have also installed all CRAN packages that do not require other 3rd
> party drivers, etc. and there were no observed errors in those cases.
>
> So far, so good.
>
> If anything comes up, I will post a follow up.
>
> Best regards,
>
> Marc Schwartz
Yep. Just tried the same on AMD64 (I had a bit of a fight converting
my SuSE setup -- FC4 is quite unhappy about ReiserFS for some reason).
A couple of f95 warnings whooshed by during the compile, that was all.
By the way, I noticed that you can now "yum install R R-devel" and get
everything straight from Fedora Extras.
--
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 2.1.1 slated for June 20
Marc Schwartz <[EMAIL PROTECTED]> writes: > Prof. Ripley, > > If my read of the config.log is correct, it would appear that g77 was > used and not gfortran (which is installed): > > ... > C compiler:gcc -g -O2 > C++ compiler: g++ -g -O2 > Fortran compiler: g77 -g -O2 > ... Mine was C compiler:gcc -g -O2 C++ compiler: g++ -g -O2 Fortran compiler: f95 -g -O2 (and f95 is a link to gfortran) -- 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 2.1.1 slated for June 20
On Tue, 2005-06-14 at 23:52 +0200, Peter Dalgaard wrote:
> Marc Schwartz <[EMAIL PROTECTED]> writes:
>
> > On Fri, 2005-06-10 at 14:57 +0100, Prof Brian Ripley wrote:
> > > On Fri, 10 Jun 2005, Peter Dalgaard wrote:
> > >
> > > > The next version of R will be released (barring force majeure) on June
> > > > 20th, with beta versions available starting Monday.
> > > >
> > > > Please do check them on your system *before* the release this time...
> > >
> > > Some things which it would be particularly helpful to have tested:
> >
> >
> > > - Bleeding-edge OSes, e.g. anyone running Fedora Core 4 test 3? (These
> > >often show up problems with bugs in the pre-release versions of
> > >components such as X11 and compilers.)
> >
> >
> > Just as a quick heads up, I installed FC4 Release ("Stentz") late
> > yesterday.
> >
> > R (Version 2.1.1 beta (2005-06-14)) compiles fine using:
> >
> > $ gcc --version
> > gcc (GCC) 4.0.0 20050519 (Red Hat 4.0.0-8)
> >
> > and make check-all passes with no problems.
> >
> > I have also installed all CRAN packages that do not require other 3rd
> > party drivers, etc. and there were no observed errors in those cases.
> >
> > So far, so good.
> >
> > If anything comes up, I will post a follow up.
> >
> > Best regards,
> >
> > Marc Schwartz
>
> Yep. Just tried the same on AMD64 (I had a bit of a fight converting
> my SuSE setup -- FC4 is quite unhappy about ReiserFS for some reason).
> A couple of f95 warnings whooshed by during the compile, that was all.
>
> By the way, I noticed that you can now "yum install R R-devel" and get
> everything straight from Fedora Extras.
Yep. Tom "Spot" Callaway is the FE maintainer for R.
A lot of things for FC 4 have been moved to Extras and there are of
course new things (like R) there as well. The restrictions on non-GPL
components is still there, so things like MP3 functionality is available
via third party repos such as FreshRPMS, Livna, etc.
This was a "balancing" act between trying to reduce (manage) the size of
the main distro and reducing real or perceived redundancies in packages.
So, for example:
1. Include OO.org in Core, but move Gnumeric to Extras
2. Include Emacs in Core, but move XEmacs to Extras
Needless to say, that resulted in "emotional" discussions.
Marc
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 2.1.1 slated for June 20
On Wed, 2005-06-15 at 00:01 +0200, Peter Dalgaard wrote: > Marc Schwartz <[EMAIL PROTECTED]> writes: > > > Prof. Ripley, > > > > If my read of the config.log is correct, it would appear that g77 was > > used and not gfortran (which is installed): > > > > ... > > C compiler:gcc -g -O2 > > C++ compiler: g++ -g -O2 > > Fortran compiler: g77 -g -O2 > > ... > > Mine was > > > C compiler:gcc -g -O2 > C++ compiler: g++ -g -O2 > Fortran compiler: f95 -g -O2 > > (and f95 is a link to gfortran) Interesting. Did you do anything different on the ./configure line? $ ls -l /usr/bin/f95 lrwxrwxrwx 1 root root 8 Jun 13 21:18 /usr/bin/f95 -> gfortran I just tried it again (having installed some FC updates) and I still get g77... Marc __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Citation for R
As a biologist, I have been following this thread with interest. I don't understand how someone can truly peer-review any software without access to the source. Surely R is the only major environment for statistical programming that _can_ be peer-reviewed in that sense. (The BUGS project is heading in that direction with OpenBUGS.) All the others (SAS, SPSS etc.) rely on their "prestige", since they are unwilling to show us exactly how they do their computations. I agree that the citation problem is not a bug in R, but a bug in the publishers. It is up to the users to aggressively tackle resistance to citing correctly published software (ie software with an ISBN number,as opposed to in-house publishing of User manuals etc.). Perhaps the R Development Core Team could provide a position statement on the citation and publication of R that could be used to convince editors that the current citation method for R is correct and appropriate. If it were signed by all the members, with their academic affiliations, it would be hard for editors to disagree. Simon. >On 14-Jun-05 A.J. Rossini wrote: >> Fritz - >> >> That's silly. As someone pointed out, the issue is with the >> publisher, not the citation. If R-Core were a generally well-known >> and regarded publishing house such as Springer or Microsoft, it would >> not be a problem. But it's still a nebulous entity to MANY people, >> and so many people fail to understand this open source stuff. It's >> seriously discouraged by most journals to cite technical reports, for >> example. And perhaps, R could be considered more of a long-ish >> technical report than a book? Though perhaps Peter D. could be >> considered the "editor"? (these questions are not those that I need >> to ask, obviously!) >> >> (just yesterday, I was asked by a reasonably intelligent colleague, >> with respect to corporate packaging of R: "So they (corporate >> packagers) just pick some version and package it, right?" and my >> flabbergasted response was: >> >> "and so, what the heck do you think they (corporate packagers) do with >> SAS, S-PLUS, and SPSS, and why do you think it's different...?"). >> >> best, >> -tony > >Tony is getting admirably and justifiably tetchy! His comment >about the packaging of SAS, S-PLUS and SPSS is delightfully >to the point (and, had I been there at the time, I'd have >bought him a beverage of his choice in appreciation). > >And, to extend his comment, where for instance does that leave >WinBUGS (see my previous mail)? Granted, perhaps, that in the >citation > > > Spiegelhalter, D. J., Thomas, A. and Best, N. G. (2000) > WinBUGS Version 1.3 User Manual. Cambridge: Medical Research > Council Biostatistics Unit. > (Available from www.mrc-bsu.cam.ac.uk/bugs.) > > >one has a prestigious institute (MRC-BSU) as the publisher. >But, basically, it's the same self-justifiying ordinance all >over again: the creators of the software produce their own >User Manual and "publish" it. The publisher of S-PLUS and its >documentation is "Insightful Corporation": beyond their >achievement in developing S-PLUS, whence their prestige? >(Granted, again, if you look inside the books, you can find >famous names listed as contributors; but we at R can claim >many of these same names ... ). > >The issue of "peer review" of software citations has been >raised. Where is the peer review of the S-PLUS or SAS or >SPSS User Manual? OK, the thing that needs peer review is >the software itself. In the "Review" section of journals >you can find critical reviews of software. But these are >not referee'd and usually represent the writer's own views; >furthermore, such reviews are not often cited in articles >where the software has been used to obtain the results in >the article. People just use the stuff, and cite the User >Manual or the "corporate packager". > >Also, from time to time you come across published referee'd >articles which analyse the performance of software for >particular purposes, or compare different software packages >for a given purpose. These could be viewed as peer review, >but, again, are rarely cited by the simple user. > >Moreover, suppose that citing User Manual or corporate packager >is considered to justify the use of the software in an article. >I have seen many articles where such-and-such software was used >(I mention no names) and "cited" in these terms, where it is >known to discerning users that the software does not correctly >address the tasks it claims to work for, or gives incorrect >results. Yet the "citation box" had been duly ticked, and the >article has successfully gone through the editorial process. >This is not peer review either -- and could only come close to >it if the journal editors' panel of referees could be assumed >sufficiently knowledgeable to be discriminating about such things. > >But in that case you don't really need a citation: the referee >says "Used [e.g.] S-PLUS, yes, that's fi
Re: [Rd] R 2.1.1 slated for June 20
On Jun 14, 2005, at 6:16 PM, Marc Schwartz wrote: > Interesting. Did you do anything different on the ./configure line? > > $ ls -l /usr/bin/f95 > lrwxrwxrwx 1 root root 8 Jun 13 21:18 /usr/bin/f95 -> gfortran > > I just tried it again (having installed some FC updates) and I > still get g77... g77 is probed before f95, so if you have both, g77 is picked unless you set F77 explicitly. The exact probe sequence is: g77 f77 xlf frt pgf77 fort77 fl32 af77 f90 xlf90 pgf90 epcf90 f95 fort xlf95 ifc efc pgf95 lf95 gfortran (R 2.1.1 beta) g77 fort77 f77 xlf frt pgf77 cf77 fl32 af77 f95 fort xlf95 ifort ifc efc pgf95 lf95 gfortran ftn g95 f90 xlf90 pgf90 pghpf epcf90 fc (R- devel) I guess Peter simply didn't install g77. Cheers, Simon __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 2.1.1 slated for June 20
For completeness, I also just tried the R 2.1.1 snapshot from yesterday with gcc-4.0, g++-4.0 and gfortran-4.0 in an up-to-date Debian unstable chroot -- no issues to report from the build and regression test. Haven't run that version as I currently do not have a system running unstable, though. The new package based on R 2.1.1 beta also built on all autobuilders, with the exceptions of mips and mipsel which appear to be lacking working blas libs causing an aborted built on these two. Dirk -- Statistics: The (futile) attempt to offer certainty about uncertainty. -- Roger Koenker, 'Dictionary of Received Ideas of Statistics' __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 2.1.1 slated for June 20
On Tue, 2005-06-14 at 22:42 -0400, Simon Urbanek wrote: > On Jun 14, 2005, at 6:16 PM, Marc Schwartz wrote: > > > Interesting. Did you do anything different on the ./configure line? > > > > $ ls -l /usr/bin/f95 > > lrwxrwxrwx 1 root root 8 Jun 13 21:18 /usr/bin/f95 -> gfortran > > > > I just tried it again (having installed some FC updates) and I > > still get g77... > > g77 is probed before f95, so if you have both, g77 is picked unless > you set F77 explicitly. The exact probe sequence is: > > g77 f77 xlf frt pgf77 fort77 fl32 af77 f90 xlf90 pgf90 epcf90 f95 > fort xlf95 ifc efc pgf95 lf95 gfortran (R 2.1.1 beta) > g77 fort77 f77 xlf frt pgf77 cf77 fl32 af77 f95 fort xlf95 ifort ifc > efc pgf95 lf95 gfortran ftn g95 f90 xlf90 pgf90 pghpf epcf90 fc (R- > devel) > > I guess Peter simply didn't install g77. > > Cheers, > Simon Simon, Thanks for that. When I installed FC4, I used the option to install "Everything", which is what I have done with each prior release going back to RH 8.0. Of course with many things being moved to Extras, "Everything" is now a shadow of it's former meaning. It is noted that "Everything" includes RPMS that are not explicitly listed in other pre-defined groups for installation. In reviewing the Add/Remove Application GUI, gfortran is listed as an "Extra Package" in the Development Tools Group. g77 is not listed in that Group or in the Legacy Development Group, so it would appear that it is a "silent" part of the "Everything" installation procedure. Removing the offending RPM: rpm -e compat-gcc-32-g77-3.2.3-47.fc4 I now get: C compiler:gcc -g -O2 C++ compiler: g++ -g -O2 Fortran compiler: f95 -g -O2 I re-compiled and did note the warning messages that I believe Peter referred to: f95 -g -O2 -c blas.f -o blas.o In file blas.f:1561 GO TO IGO,(120,150,180,210) 1 Warning: Obsolete: Assigned GOTO statement at (1) In file blas.f:1567 ASSIGN 120 TO IGO 1 Warning: Obsolete: ASSIGN statement at (1) In file blas.f:1579 ASSIGN 150 TO IGO 1 Warning: Obsolete: ASSIGN statement at (1) In file blas.f:1592 ASSIGN 180 TO IGO 1 Warning: Obsolete: ASSIGN statement at (1) In file blas.f:1603 ASSIGN 210 TO IGO 1 Warning: Obsolete: ASSIGN statement at (1) make check-all passes with no errors, so no change there. Regards, Marc __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 2.1.1 slated for June 20
Our preference is F77 compilers over F9x ones, as the lists Simon showed reflects - we decided to prefer F95 to F90 in future, though. My experience is that g77 from gcc-3.4.x is preferable to gfortran. As I said earlier, once gcc-4.0.1 is released (and so R builds with a released version of gcc-4.x.y - 4.0.0 needs worarounds) I will take a another look. So far, using gcc-3.4.4 is both faster and more accurate that gcc-4.0.0. There are a few instances in which loess gives rather different results with gfortran, but they are only visible by diffing postscript files. I will look into converting blas.f to F77 (but not for this release). On Tue, 14 Jun 2005, Marc Schwartz wrote: > On Tue, 2005-06-14 at 22:42 -0400, Simon Urbanek wrote: >> On Jun 14, 2005, at 6:16 PM, Marc Schwartz wrote: >> >>> Interesting. Did you do anything different on the ./configure line? >>> >>> $ ls -l /usr/bin/f95 >>> lrwxrwxrwx 1 root root 8 Jun 13 21:18 /usr/bin/f95 -> gfortran >>> >>> I just tried it again (having installed some FC updates) and I >>> still get g77... >> >> g77 is probed before f95, so if you have both, g77 is picked unless >> you set F77 explicitly. The exact probe sequence is: >> >> g77 f77 xlf frt pgf77 fort77 fl32 af77 f90 xlf90 pgf90 epcf90 f95 >> fort xlf95 ifc efc pgf95 lf95 gfortran (R 2.1.1 beta) >> g77 fort77 f77 xlf frt pgf77 cf77 fl32 af77 f95 fort xlf95 ifort ifc >> efc pgf95 lf95 gfortran ftn g95 f90 xlf90 pgf90 pghpf epcf90 fc (R- >> devel) >> >> I guess Peter simply didn't install g77. >> >> Cheers, >> Simon > > Simon, > > Thanks for that. When I installed FC4, I used the option to install > "Everything", which is what I have done with each prior release going > back to RH 8.0. Of course with many things being moved to Extras, > "Everything" is now a shadow of it's former meaning. > > It is noted that "Everything" includes RPMS that are not explicitly > listed in other pre-defined groups for installation. > > In reviewing the Add/Remove Application GUI, gfortran is listed as an > "Extra Package" in the Development Tools Group. > > g77 is not listed in that Group or in the Legacy Development Group, so > it would appear that it is a "silent" part of the "Everything" > installation procedure. > > Removing the offending RPM: > > rpm -e compat-gcc-32-g77-3.2.3-47.fc4 > > I now get: > > C compiler:gcc -g -O2 > C++ compiler: g++ -g -O2 > Fortran compiler: f95 -g -O2 > > > I re-compiled and did note the warning messages that I believe Peter > referred to: > > f95 -g -O2 -c blas.f -o blas.o > In file blas.f:1561 > > GO TO IGO,(120,150,180,210) > 1 > Warning: Obsolete: Assigned GOTO statement at (1) > In file blas.f:1567 > > ASSIGN 120 TO IGO > 1 > Warning: Obsolete: ASSIGN statement at (1) > In file blas.f:1579 > > ASSIGN 150 TO IGO > 1 > Warning: Obsolete: ASSIGN statement at (1) > In file blas.f:1592 > > ASSIGN 180 TO IGO > 1 > Warning: Obsolete: ASSIGN statement at (1) > In file blas.f:1603 > > ASSIGN 210 TO IGO > 1 > Warning: Obsolete: ASSIGN statement at (1) > > > > make check-all passes with no errors, so no change there. > > > Regards, > > Marc > > > -- 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
