Re: [Rd] R vs. C
Tests and examples are different things. The fact that your example runs only means that your code does not bomb on execution and not that it runs correctly. Plus, the code in examples is meant as an aid to the user; a way to help them understand how to use your code. Proper tests are there to make sure your code executes properly and computes things correctly. [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R vs. C now rather: how to ease package checking
On 1/18/2011 8:44 AM, Dominick Samperi wrote: On Tue, Jan 18, 2011 at 4:48 AM, Claudia Beleiteswrote: On 01/18/2011 01:13 AM, Dominick Samperi wrote: On Mon, Jan 17, 2011 at 7:00 PM, Spencer Graves< spencer.gra...@structuremonitoring.com> wrote: Hi, Dominick, et al.: Demanding complete unit test suites with all software contributed to CRAN would likely cut contributions by a factor of 10 or 100. For me, the R package creation process is close to perfection in providing a standard process for documentation with places for examples and test suites of various kinds. I mention "perfection", because it makes developing "trustworthy software" (Chamber's "prime directive") relatively easy without forcing people to do things they don't feel comfortable doing. I don't think I made myself clear, sorry. I was not suggesting that package developers include a complete unit test suite. I was suggesting that unit testing should be done outside of the CRAN release process. Packages should be submitted for "release" to CRAN after they have been tested (the responsibility of the package developers). I understand that the main problem here is that package developers do not have access to all supported platforms, so the current process is not likely to change. Regarding access to all platforms: But there's r-forge where building and checks are done nightly for Linux, Win, and Mac (though for some months now the check protocols are not available for 32 bit Linux and Windows - but I hope they'll be back soon). I found it extremely easy to get an account& project space and building. Many thanks to r-forge! Good point Claudia, There are packages released to CRAN that do not build on some platforms because the unit tests fail. It seems to me that this kind of issue could be ironed out with the help of r-forge before release, in which case there is no need to run the unit tests for released packages. Dominick CRAN also runs "R CMD check" on its contributed packages. I've found problems (and fixed) that I couldn't replicate by reviewing the repeated checks on both R-Forge and CRAN. Spencer [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Spencer Graves, PE, PhD President and Chief Operating Officer Structure Inspection and Monitoring, Inc. 751 Emerson Ct. San José, CA 95126 ph: 408-655-4567 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] format scientific + plotmath potential bug
I already had a solution under test, so the bug is now fixed and
closed.
On Tue, 18 Jan 2011, Duncan Murdoch wrote:
On 17/01/2011 5:06 PM, Philip Johnson wrote:
I have run into a potential bug somewhere between format (specifically
scientific notation) and plotmath that results in displaying:
$1e+01^{2e+00}$
instead of
$10^2$
Reproduce by:
plot.new()
a=format(10, scientific=TRUE)
mtext(expression(10^2), line=1) # looks like $1e+01^{2e+00}$
10 # this fixes the problem on the next line
mtext(expression(10^2), line=2) # looks like $10^2$
I can narrow the trigger somewhat further by replacing the "a=..." line
with:
a=.Internal(format(10, FALSE, NULL, 0L, NULL, 3L, TRUE, TRUE))
Tracing this call into the C started giving me a headache, so I'm hoping
that one of the R core gurus can confirm& file a bug report if necessary.
I ran into this on Ubuntu / Lucid using R version 2.10.1 (2009-12-14).
I confirmed it still exists in R 2.12.1 (2010-12-16) on a fresh install
of Ubuntu / Maverick.
Yes, I see this too in R-devel and 2.12.1. Definitely a bug, and I've
submitted it to the bug system:
https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=14477
If you want to be kept up to date about fixes you can add yourself to the CC
list there.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Brian D. Ripley, rip...@stats.ox.ac.uk
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 vs. C now rather: how to ease package checking
On Tue, Jan 18, 2011 at 4:48 AM, Claudia Beleites wrote: > On 01/18/2011 01:13 AM, Dominick Samperi wrote: > >> On Mon, Jan 17, 2011 at 7:00 PM, Spencer Graves< >> spencer.gra...@structuremonitoring.com> wrote: >> >> Hi, Dominick, et al.: >>> >>> >>> Demanding complete unit test suites with all software contributed to >>> CRAN would likely cut contributions by a factor of 10 or 100. For me, >>> the R >>> package creation process is close to perfection in providing a standard >>> process for documentation with places for examples and test suites of >>> various kinds. I mention "perfection", because it makes developing >>> "trustworthy software" (Chamber's "prime directive") relatively easy >>> without >>> forcing people to do things they don't feel comfortable doing. >>> >>> >> I don't think I made myself clear, sorry. I was not suggesting that >> package >> developers include a complete unit >> test suite. I was suggesting that unit testing should be done outside of >> the >> CRAN release process. Packages >> should be submitted for "release" to CRAN after they have been tested (the >> responsibility of the package >> developers). I understand that the main problem here is that package >> developers do not have access to >> all supported platforms, so the current process is not likely to change. >> > > Regarding access to all platforms: But there's r-forge where building and > checks are done nightly for Linux, Win, and Mac (though for some months now > the check protocols are not available for 32 bit Linux and Windows - but I > hope they'll be back soon). > I found it extremely easy to get an account & project space and building. > Many thanks to r-forge! > Good point Claudia, There are packages released to CRAN that do not build on some platforms because the unit tests fail. It seems to me that this kind of issue could be ironed out with the help of r-forge before release, in which case there is no need to run the unit tests for released packages. Dominick [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RPostgreSQL 0.1.7 for Windows 64 causes R.2.12.1 Win64 crash
Hi Professor Brian :
I buy a new 64bit Win7 Home basic notebook for working with 64bit R
and PostgreSQL :)
but still now I can't get postgresql-9.0.2-1-windows_x64 installed.
Which version of Win 7 and postgres do you use, can you share the
download URL for 9.0.0.1 of 64bit PostgreSQL, I can't find it form
EnterpriseDB now.
Thanks.
Xiaobo Gu
On Tue, Jan 18, 2011 at 1:22 AM, Prof Brian Ripley
wrote:
> On Mon, 17 Jan 2011, Dirk Eddelbuettel wrote:
>
>>
>> On 16 January 2011 at 23:00, Xiaobo Gu wrote:
>> | Is it because of compiler campsites between R and PostgreSQL, R is
>> | compiled by GCC, while PostgreSQL from Enterprise DB is compiled by
>> | Microsoft Visual C ++.
>>
>> So the usual recommendation is to build the matching library (here libpq)
>> with the same compiler, or get the commercial support you are paying for
>> to
>> do it for you.
>>
>> For what it is worth, I deal with one vendor at work where I made that
>> requirement and they had no issue complying / helping me with a MinGW /
>> Rtools-compatible library. One of several reasons I like working with
>> that
>> vendor.
>
> And also for what it is worth, RPostgreSQL works for me on x64 Windows 7
> compiled with the Rtools compilers and linked against the initial PostgreSQL
> 9.0 Windows x64 distribution (I've not tried the one you mentioned).
>
> Where C (and not C++) is involved it should be possible to mix DLLs compiled
> by MinGW-w64 and MSVC, and this has been done extensively (after all a lot
> of Windows' own DLLs are compiled with MSVC, as are the Tcl/Tk binaries
> which are distributed with R).
>
>>
>> Dirk
>>
>> | Xiaobo Gu
>> |
>> | On Sat, Jan 15, 2011 at 10:34 AM, Xiaobo Gu
>> wrote:
>> | > Hi,
>> | > I build the binary package file of RPostgreSQL 0.1.7 for Windows 2003
>> | > Server R2 64 bit SP2, the software environments are as following:
>> | > R 2.12.1 for Win64
>> | > RTools212 for Win64
>> | > DBI 0.2.5
>> | > RPostgreSQL 0.1.7
>> | > Postgresql related binaries shipped with
>> | > postgresql-9.0.2-1-windows_x64.exe from EnterpriseDB
>> | >
>> | > The package can be loaded, and driver can be created, but the
>> | > dbConnect function causes the whole RGui crashes,
>> | >
>> | > driver <- dbDriver("PostgreSQL")
>> | > con <- dbConnect(driver, dbname="demo", host="192.168.8.1",
>> | > user="postgres", password="postgres", port=5432)
>> | >
>> |
>> | __
>> | R-devel@r-project.org mailing list
>> | https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>> --
>> Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
> --
> Brian D. Ripley, rip...@stats.ox.ac.uk
> 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, UK Fax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] format scientific + plotmath potential bug
On 17/01/2011 5:06 PM, Philip Johnson wrote:
I have run into a potential bug somewhere between format (specifically
scientific notation) and plotmath that results in displaying:
$1e+01^{2e+00}$
instead of
$10^2$
Reproduce by:
plot.new()
a=format(10, scientific=TRUE)
mtext(expression(10^2), line=1) # looks like $1e+01^{2e+00}$
10 # this fixes the problem on the next line
mtext(expression(10^2), line=2) # looks like $10^2$
I can narrow the trigger somewhat further by replacing the "a=..." line
with:
a=.Internal(format(10, FALSE, NULL, 0L, NULL, 3L, TRUE, TRUE))
Tracing this call into the C started giving me a headache, so I'm hoping
that one of the R core gurus can confirm& file a bug report if necessary.
I ran into this on Ubuntu / Lucid using R version 2.10.1 (2009-12-14).
I confirmed it still exists in R 2.12.1 (2010-12-16) on a fresh install
of Ubuntu / Maverick.
Yes, I see this too in R-devel and 2.12.1. Definitely a bug, and I've
submitted it to the bug system:
https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=14477
If you want to be kept up to date about fixes you can add yourself to
the CC list there.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] format scientific + plotmath potential bug
I have run into a potential bug somewhere between format (specifically
scientific notation) and plotmath that results in displaying:
$1e+01^{2e+00}$
instead of
$10^2$
Reproduce by:
plot.new()
a=format(10, scientific=TRUE)
mtext(expression(10^2), line=1) # looks like $1e+01^{2e+00}$
10 # this fixes the problem on the next line
mtext(expression(10^2), line=2) # looks like $10^2$
I can narrow the trigger somewhat further by replacing the "a=..." line
with:
a=.Internal(format(10, FALSE, NULL, 0L, NULL, 3L, TRUE, TRUE))
Tracing this call into the C started giving me a headache, so I'm hoping
that one of the R core gurus can confirm & file a bug report if necessary.
I ran into this on Ubuntu / Lucid using R version 2.10.1 (2009-12-14).
I confirmed it still exists in R 2.12.1 (2010-12-16) on a fresh install
of Ubuntu / Maverick.
Thanks,
Philip
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R vs. C
Claudia,
I think we agree.
Having the examples run in the
tests is a good thing, I think.
They might strengthen the tests
some (especially if there are
no other tests). But mainly if
examples don't work, then it's
hard to have much faith in the
code.
On 18/01/2011 11:36, Claudia Beleites wrote:
On 01/18/2011 10:53 AM, Patrick Burns wrote:
I'm not at all a fan of thinking
of the examples as being tests.
Examples should clarify the thinking
of potential users. Tests should
clarify the space in which the code
is correct. These two goals are
generally at odds.
Patrick, I completely agree with you that
- Tests should not clutter the documentation and go to their proper place.
- Examples are there for the user's benefit - and must be written
accordingly.
- Often, test should cover far more situations than good examples.
Yet it seems to me that (part of the) examples are justly considered a
(small) subset of the tests:
As a potential user, I reqest two things from good examples that have an
implicit testing message/side effect:
- I like the examples to roughly outline the space in which the code
works: they should tell me what I'm supposed to do.
- Depending on the function's purpose, I like to see a demonstration of
the correctness for some example calculation.
(I don't want to see all further tests - I can look them up if I feel
the need)
The fact that the very same line of example code serves a testing (side)
purpose doesn't mean that it should be copied into the tests, does it?
Thus, I think of the "public" part (the "preface") of the tests living
in the examples.
My 2 ct,
Best regards,
Claudia
On 17/01/2011 22:15, Spencer Graves wrote:
Hi, Paul:
The "Writing R Extensions" manual says that *.R code in a "tests"
directory is run during "R CMD check". I suspect that many R programmers
do this routinely. I probably should do that also. However, for me, it's
simpler to have everything in the "examples" section of *.Rd files. I
think the examples with independently developed answers provides useful
documentation.
Spencer
On 1/17/2011 1:52 PM, Paul Gilbert wrote:
Spencer
Would it not be easier to include this kind of test in a small file in
the tests/ directory?
Paul
-Original Message-
From: r-devel-boun...@r-project.org
[mailto:r-devel-boun...@r-project.org] On Behalf Of Spencer Graves
Sent: January 17, 2011 3:58 PM
To: Dominick Samperi
Cc: Patrick Leyshock; r-devel@r-project.org; Dirk Eddelbuettel
Subject: Re: [Rd] R vs. C
For me, a major strength of R is the package development
process. I've found this so valuable that I created a Wikipedia entry
by that name and made additions to a Wikipedia entry on "software
repository", noting that this process encourages good software
development practices that I have not seen standardized for other
languages. I encourage people to review this material and make
additions or corrections as they like (or sent me suggestions for me to
make appropriate changes).
While R has other capabilities for unit and regression testing, I
often include unit tests in the "examples" section of documentation
files. To keep from cluttering the examples with unnecessary material,
I often include something like the following:
A1<- myfunc() # to test myfunc
A0<- ("manual generation of the correct answer for A1")
\dontshow{stopifnot(} # so the user doesn't see "stopifnot("
all.equal(A1, A0) # compare myfunc output with the correct answer
\dontshow{)} # close paren on "stopifnot(".
This may not be as good in some ways as a full suite of unit
tests, which could be provided separately. However, this has the
distinct advantage of including unit tests with the documentation in a
way that should help users understand "myfunc". (Unit tests too
detailed to show users could be completely enclosed in "\dontshow".
Spencer
On 1/17/2011 11:38 AM, Dominick Samperi wrote:
On Mon, Jan 17, 2011 at 2:08 PM, Spencer Graves<
spencer.gra...@structuremonitoring.com> wrote:
Another point I have not yet seen mentioned: If your code is
painfully slow, that can often be fixed without leaving R by
experimenting
with different ways of doing the same thing -- often after using
profiling
your code to find the slowest part as described in chapter 3 of
"Writing R
Extensions".
If I'm given code already written in C (or some other language),
unless it's really simple, I may link to it rather than recode it
in R.
However, the problems with portability, maintainability,
transparency to
others who may not be very facile with C, etc., all suggest that
it's well
worth some effort experimenting with alternate ways of doing the
same thing
in R before jumping to C or something else.
Hope this helps.
Spencer
On 1/17/2011 10:57 AM, David Henderson wrote:
I think we're also forgetting something, namely testing. If you
write
your
routine in C, you have placed additional burden upon yourself to
test your
C
code through unit tests, etc. If you write your code in R, you
still need
t
Re: [Rd] R vs. C
On 01/18/2011 10:53 AM, Patrick Burns wrote:
I'm not at all a fan of thinking
of the examples as being tests.
Examples should clarify the thinking
of potential users. Tests should
clarify the space in which the code
is correct. These two goals are
generally at odds.
Patrick, I completely agree with you that
- Tests should not clutter the documentation and go to their proper place.
- Examples are there for the user's benefit - and must be written accordingly.
- Often, test should cover far more situations than good examples.
Yet it seems to me that (part of the) examples are justly considered a (small)
subset of the tests:
As a potential user, I reqest two things from good examples that have an
implicit testing message/side effect:
- I like the examples to roughly outline the space in which the code works: they
should tell me what I'm supposed to do.
- Depending on the function's purpose, I like to see a demonstration of the
correctness for some example calculation.
(I don't want to see all further tests - I can look them up if I feel the need)
The fact that the very same line of example code serves a testing (side) purpose
doesn't mean that it should be copied into the tests, does it?
Thus, I think of the "public" part (the "preface") of the tests living in the
examples.
My 2 ct,
Best regards,
Claudia
On 17/01/2011 22:15, Spencer Graves wrote:
Hi, Paul:
The "Writing R Extensions" manual says that *.R code in a "tests"
directory is run during "R CMD check". I suspect that many R programmers
do this routinely. I probably should do that also. However, for me, it's
simpler to have everything in the "examples" section of *.Rd files. I
think the examples with independently developed answers provides useful
documentation.
Spencer
On 1/17/2011 1:52 PM, Paul Gilbert wrote:
Spencer
Would it not be easier to include this kind of test in a small file in
the tests/ directory?
Paul
-Original Message-
From: r-devel-boun...@r-project.org
[mailto:r-devel-boun...@r-project.org] On Behalf Of Spencer Graves
Sent: January 17, 2011 3:58 PM
To: Dominick Samperi
Cc: Patrick Leyshock; r-devel@r-project.org; Dirk Eddelbuettel
Subject: Re: [Rd] R vs. C
For me, a major strength of R is the package development
process. I've found this so valuable that I created a Wikipedia entry
by that name and made additions to a Wikipedia entry on "software
repository", noting that this process encourages good software
development practices that I have not seen standardized for other
languages. I encourage people to review this material and make
additions or corrections as they like (or sent me suggestions for me to
make appropriate changes).
While R has other capabilities for unit and regression testing, I
often include unit tests in the "examples" section of documentation
files. To keep from cluttering the examples with unnecessary material,
I often include something like the following:
A1<- myfunc() # to test myfunc
A0<- ("manual generation of the correct answer for A1")
\dontshow{stopifnot(} # so the user doesn't see "stopifnot("
all.equal(A1, A0) # compare myfunc output with the correct answer
\dontshow{)} # close paren on "stopifnot(".
This may not be as good in some ways as a full suite of unit
tests, which could be provided separately. However, this has the
distinct advantage of including unit tests with the documentation in a
way that should help users understand "myfunc". (Unit tests too
detailed to show users could be completely enclosed in "\dontshow".
Spencer
On 1/17/2011 11:38 AM, Dominick Samperi wrote:
On Mon, Jan 17, 2011 at 2:08 PM, Spencer Graves<
spencer.gra...@structuremonitoring.com> wrote:
Another point I have not yet seen mentioned: If your code is
painfully slow, that can often be fixed without leaving R by
experimenting
with different ways of doing the same thing -- often after using
profiling
your code to find the slowest part as described in chapter 3 of
"Writing R
Extensions".
If I'm given code already written in C (or some other language),
unless it's really simple, I may link to it rather than recode it in R.
However, the problems with portability, maintainability,
transparency to
others who may not be very facile with C, etc., all suggest that
it's well
worth some effort experimenting with alternate ways of doing the
same thing
in R before jumping to C or something else.
Hope this helps.
Spencer
On 1/17/2011 10:57 AM, David Henderson wrote:
I think we're also forgetting something, namely testing. If you write
your
routine in C, you have placed additional burden upon yourself to
test your
C
code through unit tests, etc. If you write your code in R, you
still need
the
unit tests, but you can rely on the well tested nature of R to
allow you
to
reduce the number of tests of your algorithm. I routinely tell
people at
Sage
Bionetworks where I am working now that your new C code needs to
experience at
least one order of magnitude increase in performance to
Re: [Rd] R vs. C
I'm not at all a fan of thinking
of the examples as being tests.
Examples should clarify the thinking
of potential users. Tests should
clarify the space in which the code
is correct. These two goals are
generally at odds.
On 17/01/2011 22:15, Spencer Graves wrote:
Hi, Paul:
The "Writing R Extensions" manual says that *.R code in a "tests"
directory is run during "R CMD check". I suspect that many R programmers
do this routinely. I probably should do that also. However, for me, it's
simpler to have everything in the "examples" section of *.Rd files. I
think the examples with independently developed answers provides useful
documentation.
Spencer
On 1/17/2011 1:52 PM, Paul Gilbert wrote:
Spencer
Would it not be easier to include this kind of test in a small file in
the tests/ directory?
Paul
-Original Message-
From: r-devel-boun...@r-project.org
[mailto:r-devel-boun...@r-project.org] On Behalf Of Spencer Graves
Sent: January 17, 2011 3:58 PM
To: Dominick Samperi
Cc: Patrick Leyshock; r-devel@r-project.org; Dirk Eddelbuettel
Subject: Re: [Rd] R vs. C
For me, a major strength of R is the package development
process. I've found this so valuable that I created a Wikipedia entry
by that name and made additions to a Wikipedia entry on "software
repository", noting that this process encourages good software
development practices that I have not seen standardized for other
languages. I encourage people to review this material and make
additions or corrections as they like (or sent me suggestions for me to
make appropriate changes).
While R has other capabilities for unit and regression testing, I
often include unit tests in the "examples" section of documentation
files. To keep from cluttering the examples with unnecessary material,
I often include something like the following:
A1<- myfunc() # to test myfunc
A0<- ("manual generation of the correct answer for A1")
\dontshow{stopifnot(} # so the user doesn't see "stopifnot("
all.equal(A1, A0) # compare myfunc output with the correct answer
\dontshow{)} # close paren on "stopifnot(".
This may not be as good in some ways as a full suite of unit
tests, which could be provided separately. However, this has the
distinct advantage of including unit tests with the documentation in a
way that should help users understand "myfunc". (Unit tests too
detailed to show users could be completely enclosed in "\dontshow".
Spencer
On 1/17/2011 11:38 AM, Dominick Samperi wrote:
On Mon, Jan 17, 2011 at 2:08 PM, Spencer Graves<
spencer.gra...@structuremonitoring.com> wrote:
Another point I have not yet seen mentioned: If your code is
painfully slow, that can often be fixed without leaving R by
experimenting
with different ways of doing the same thing -- often after using
profiling
your code to find the slowest part as described in chapter 3 of
"Writing R
Extensions".
If I'm given code already written in C (or some other language),
unless it's really simple, I may link to it rather than recode it in R.
However, the problems with portability, maintainability,
transparency to
others who may not be very facile with C, etc., all suggest that
it's well
worth some effort experimenting with alternate ways of doing the
same thing
in R before jumping to C or something else.
Hope this helps.
Spencer
On 1/17/2011 10:57 AM, David Henderson wrote:
I think we're also forgetting something, namely testing. If you write
your
routine in C, you have placed additional burden upon yourself to
test your
C
code through unit tests, etc. If you write your code in R, you
still need
the
unit tests, but you can rely on the well tested nature of R to
allow you
to
reduce the number of tests of your algorithm. I routinely tell
people at
Sage
Bionetworks where I am working now that your new C code needs to
experience at
least one order of magnitude increase in performance to warrant the
effort
of
moving from R to C.
But, then again, I am working with scientists who are not
primarily, or
even
secondarily, coders...
Dave H
This makes sense, but I have seem some very transparent algorithms
turned
into vectorized R code
that is difficult to read (and thus to maintain or to change). These
chunks
of optimized R code are like
embedded assembly, in the sense that nobody is likely to want to mess
with
it. This could be addressed
by including pseudo code for the original (more transparent)
algorithm as a
comment, but I have never
seen this done in practice (perhaps it could be enforced by R CMD
check?!).
On the other hand, in principle a well-documented piece of C/C++ code
could
be much easier to understand,
without paying a performance penalty...but "coders" are not likely to
place
this high on their
list of priorities.
The bottom like is that R is an adaptor ("glue") language like Lisp that
makes it easy to mix and
match functions (using classes and generic functions), many of which are
written in C (or C++
or Fortran) for performance reasons. Like any object-based system
th
Re: [Rd] R vs. C now rather: how to ease package checking
On 01/18/2011 01:13 AM, Dominick Samperi wrote:
On Mon, Jan 17, 2011 at 7:00 PM, Spencer Graves<
spencer.gra...@structuremonitoring.com> wrote:
Hi, Dominick, et al.:
Demanding complete unit test suites with all software contributed to
CRAN would likely cut contributions by a factor of 10 or 100. For me, the R
package creation process is close to perfection in providing a standard
process for documentation with places for examples and test suites of
various kinds. I mention "perfection", because it makes developing
"trustworthy software" (Chamber's "prime directive") relatively easy without
forcing people to do things they don't feel comfortable doing.
I don't think I made myself clear, sorry. I was not suggesting that package
developers include a complete unit
test suite. I was suggesting that unit testing should be done outside of the
CRAN release process. Packages
should be submitted for "release" to CRAN after they have been tested (the
responsibility of the package
developers). I understand that the main problem here is that package
developers do not have access to
all supported platforms, so the current process is not likely to change.
Regarding access to all platforms: But there's r-forge where building and checks
are done nightly for Linux, Win, and Mac (though for some months now the check
protocols are not available for 32 bit Linux and Windows - but I hope they'll be
back soon).
I found it extremely easy to get an account & project space and building.
Many thanks to r-forge!
complete unit test suites:
To me, it seems nicer and better to favour packages that do it than mechanical
enforcement. E.g. show icons that announce if a package comes with vignette,
test suite (code coverage), and etc.
My 2 ct,
Claudia
Dominick
If you need more confidence in the software you use, you can build
your own test suites -- maybe in packages you write yourself -- or pay
someone else to develop test suites to your specifications. For example,
Revolution Analytics offers "Package validation, development and support".
Spencer
On 1/17/2011 3:27 PM, Dominick Samperi wrote:
On Mon, Jan 17, 2011 at 5:15 PM, Spencer Graves<
spencer.gra...@structuremonitoring.com> wrote:
Hi, Paul:
The "Writing R Extensions" manual says that *.R code in a "tests"
directory is run during "R CMD check". I suspect that many R programmers
do
this routinely. I probably should do that also. However, for me, it's
simpler to have everything in the "examples" section of *.Rd files. I
think
the examples with independently developed answers provides useful
documentation.
This is a unit test function, and I think it would be better if there
was a
way to unit test packages *before* they
are released to CRAN. Otherwise, this is not really a "release," it is
test
or "beta" version. This is currently
possible under Windows using http://win-builder.r-project.org/, for
example.
My earlier remark about the release process was more about documentation
than about unit testing, more
about the gentle "nudging" that the R release process does to help insure
consistent documentation and
organization, and about how this nudging might be extended to the C/C++
part
of a package.
Dominick
Spencer
On 1/17/2011 1:52 PM, Paul Gilbert wrote:
Spencer
Would it not be easier to include this kind of test in a small file in
the
tests/ directory?
Paul
-Original Message-
From: r-devel-boun...@r-project.org [mailto:
r-devel-boun...@r-project.org]
On Behalf Of Spencer Graves
Sent: January 17, 2011 3:58 PM
To: Dominick Samperi
Cc: Patrick Leyshock; r-devel@r-project.org; Dirk Eddelbuettel
Subject: Re: [Rd] R vs. C
For me, a major strength of R is the package development
process. I've found this so valuable that I created a Wikipedia entry
by that name and made additions to a Wikipedia entry on "software
repository", noting that this process encourages good software
development practices that I have not seen standardized for other
languages. I encourage people to review this material and make
additions or corrections as they like (or sent me suggestions for me to
make appropriate changes).
While R has other capabilities for unit and regression testing, I
often include unit tests in the "examples" section of documentation
files. To keep from cluttering the examples with unnecessary material,
I often include something like the following:
A1<- myfunc() # to test myfunc
A0<- ("manual generation of the correct answer for A1")
\dontshow{stopifnot(} # so the user doesn't see "stopifnot("
all.equal(A1, A0) # compare myfunc output with the correct answer
\dontshow{)} # close paren on "stopifnot(".
This may not be as good in some ways as a full suite of unit
tests, which could be provided separately. However, this has the
distinct advantage of including unit tests with the documentation in a
way that should help users understand "myfunc". (Unit t
