Re: [Rd] log(i, base=i) not giving 1
> Prof Brian Ripley
> on Wed, 3 Sep 2014 06:46:47 +0100 writes:
> On 02/09/2014 22:43, Ben Bolker wrote:
>> On 14-09-02 08:48 AM, Martin Maechler wrote:
peter dalgaard
on Tue, 2 Sep 2014 13:43:21 +0200 writes:
>>>
>>> > Impressive. Never ceases to amaze me what computers can do these
days. ;-)
>>>
>>> Indeed,
>>>
>>> > It's even more impressive given that we have
>>>
>>>
>>> > static double logbase(double x, double base)
>>> > {
>>> > #ifdef HAVE_LOG10
>>> > if(base == 10) return x > 0 ? log10(x) : x < 0 ? R_NaN : R_NegInf;
>>> > #endif
>>> > #ifdef HAVE_LOG2
>>> > if(base == 2) return x > 0 ? log2(x) : x < 0 ? R_NaN : R_NegInf;
>>> > #endif
>>> > return R_log(x) / R_log(base);
>>> > }
>>>
>>> > which, except possibly for base-10 and base-2, would seem to be quite
hard to convince to return anything other than 1 if x == base
>>>
>>> Amazingly indeed, it does: From the few platforms I can try
>>> here, I only see the problem
>>> on 32 bit Linux, both an (old) ubuntu 12.04.5 and Fedora 19.
>>>
i <- 2:99; i[log(i, base=i) != 1]
>>> [1] 5 8 14 18 19 25 58 60 64 65 66 67 75 80 84 86 91
>>>
>>> so '8' is not so special (as Ben suggested) and also not the
>>> only power of two for which this happens :
>>>
i <- 2^(1:20); i[log(i, base=i) != 1]
>>> [1] 864 128 4096 8192 16384
>>>
>>> Interestingly, it does not happen on 32-bit Windows, nor on any
>>> 64-bit version of R I've tried.
>>> Yes, it is amazing that with computer arithmetic, we can't
>>> even guarantee that U / U = 1 exactly.
>>>
>>> Is it basically free to check for x == base in there, so we
>>> could change to
>>>
>>> return (x == base) ? 1. : R_log(x) / R_log(base);
>>>
>>> ?
>>
>> Should I submit a formal bug report about this, or should I assume it
>> has now been sufficiently noted by R-core?
> It is under consideration by the author (not me).
>> Opinions about whether it is better to fix in logbase (according to
>> Martin's suggestion) or in version.R (e.g. BDR's suggestion of using
>> log2(x)/3 or some other way that makes the function less sensitive) or
both?
> Yet again, it is better to write code which does not make false
> assumptions about machine arithmetic. Fixing one very rare case at the
> expense of speed for all others is not a good idea.
Well, of course, that's why I asked about the expense. If it is
neglible, as it may well be here, we have in other circumstances
opted for more platform-independence with very slight penalties,
e.g., when wrapping system library functions by our own.
After all, arithmetic in R *has* been somewhat more portable
between platforms than arithmetic in C (C++, Fortran,..) exactly
because of that.
For the present case, I'm not making a strong argument, and find
it ok to keep the current implementation, though possibly we
should mention the issue in the documentation then.
> Studying http://www.validlab.com/goldberg/addendum.html is a good idea
> for those unfamiliar with the pitfalls of i86 FPUs. It has an example
> essentially the same as this one right at the top.
Indeed.
OTOH, with this reasoning:
> Also, Ben Bolker needs to change his compiler options to ones better
> than the defaults in his unstated Linux distro. Why anyone is using
> ix86 Linux nowadays is hard to understand when x86_64 is (on all but the
> very smallest machines) faster and more reliable.
one could argue that the platforms where log(i, base=i) != 1
should become much more rare in the future, and when 99.x % of
implementations provide a feature, chances are very high that user
code will make this assumption {after all, R core code just did
for a while!} in cases that are untested and occuring very rarely,
exactly the dangerous kinds of bugs.
As R code--even R packages--will continue to be written mostly by
people who do not know about possible FP pitfalls (*) and would
attribute them to their "software", i.e. in this case R in this case,
I still see a reason for special casing, possibly even nicely
#ifdef'ed , not causing any penalty on "-ffloat-store" or
x86_64 platforms ?
(*) Our 99.x % of R users would lack too much background
context to understand the problem even when urged to "learn"
about it in some way. They will always blame R in such cases.
Martin
>>
>> Ben Bolker
>>
>>>
>>> > On 02 Sep 2014, at 03:27 , Ben Bolker wrote:
>>>
>>> >> log(8, base=8L)-1
>>> >> log(8, base=8)-1
>>> >> logvals <- setNames(log(2:25,base=2:25)-1,2:25)
>>> >> logvals[logvals!=0] ## 5,8,14,18,19,25 all == .Machine$double.eps/2
>>>
>>> > --
>>> > Peter Dalgaard, Professor,
>>> > Center for Statistics, Copenhagen B
Re: [Rd] log(i, base=i) not giving 1
Two notes:
1) For version number comparisons, we could just add a small fuzz like
floor(log(x,8)+.Machine$double.eps) and begone with the issue.
2) I did see some other spots where we use log10() to compute field widths for
decimal representation of numbers. It might be good to check whether there are
cases of log10(10^n) < n and if so, apply fuzz as above. (Ensuring that both
(log10(10^n) + fuzz > n) and (log10(10^n-1) + fuzz < n) could get tricky, but
maybe the problem just isn't there.)
-p
On 03 Sep 2014, at 10:47 , Martin Maechler wrote:
>> Prof Brian Ripley
>>on Wed, 3 Sep 2014 06:46:47 +0100 writes:
>
>> On 02/09/2014 22:43, Ben Bolker wrote:
>>> On 14-09-02 08:48 AM, Martin Maechler wrote:
> peter dalgaard
> on Tue, 2 Sep 2014 13:43:21 +0200 writes:
> Impressive. Never ceases to amaze me what computers can do these days. ;-)
Indeed,
> It's even more impressive given that we have
> static double logbase(double x, double base)
> {
> #ifdef HAVE_LOG10
> if(base == 10) return x > 0 ? log10(x) : x < 0 ? R_NaN : R_NegInf;
> #endif
> #ifdef HAVE_LOG2
> if(base == 2) return x > 0 ? log2(x) : x < 0 ? R_NaN : R_NegInf;
> #endif
> return R_log(x) / R_log(base);
> }
> which, except possibly for base-10 and base-2, would seem to be quite
> hard to convince to return anything other than 1 if x == base
Amazingly indeed, it does: From the few platforms I can try
here, I only see the problem
on 32 bit Linux, both an (old) ubuntu 12.04.5 and Fedora 19.
> i <- 2:99; i[log(i, base=i) != 1]
[1] 5 8 14 18 19 25 58 60 64 65 66 67 75 80 84 86 91
so '8' is not so special (as Ben suggested) and also not the
only power of two for which this happens :
> i <- 2^(1:20); i[log(i, base=i) != 1]
[1] 864 128 4096 8192 16384
Interestingly, it does not happen on 32-bit Windows, nor on any
64-bit version of R I've tried.
Yes, it is amazing that with computer arithmetic, we can't
even guarantee that U / U = 1 exactly.
Is it basically free to check for x == base in there, so we
could change to
return (x == base) ? 1. : R_log(x) / R_log(base);
?
>>>
>>> Should I submit a formal bug report about this, or should I assume it
>>> has now been sufficiently noted by R-core?
>
>> It is under consideration by the author (not me).
>
>>> Opinions about whether it is better to fix in logbase (according to
>>> Martin's suggestion) or in version.R (e.g. BDR's suggestion of using
>>> log2(x)/3 or some other way that makes the function less sensitive) or both?
>
>> Yet again, it is better to write code which does not make false
>> assumptions about machine arithmetic. Fixing one very rare case at the
>> expense of speed for all others is not a good idea.
>
> Well, of course, that's why I asked about the expense. If it is
> neglible, as it may well be here, we have in other circumstances
> opted for more platform-independence with very slight penalties,
> e.g., when wrapping system library functions by our own.
>
> After all, arithmetic in R *has* been somewhat more portable
> between platforms than arithmetic in C (C++, Fortran,..) exactly
> because of that.
> For the present case, I'm not making a strong argument, and find
> it ok to keep the current implementation, though possibly we
> should mention the issue in the documentation then.
>
>> Studying http://www.validlab.com/goldberg/addendum.html is a good idea
>> for those unfamiliar with the pitfalls of i86 FPUs. It has an example
>> essentially the same as this one right at the top.
>
> Indeed.
> OTOH, with this reasoning:
>
>> Also, Ben Bolker needs to change his compiler options to ones better
>> than the defaults in his unstated Linux distro. Why anyone is using
>> ix86 Linux nowadays is hard to understand when x86_64 is (on all but the
>> very smallest machines) faster and more reliable.
>
> one could argue that the platforms where log(i, base=i) != 1
> should become much more rare in the future, and when 99.x % of
> implementations provide a feature, chances are very high that user
> code will make this assumption {after all, R core code just did
> for a while!} in cases that are untested and occuring very rarely,
> exactly the dangerous kinds of bugs.
>
> As R code--even R packages--will continue to be written mostly by
> people who do not know about possible FP pitfalls (*) and would
> attribute them to their "software", i.e. in this case R in this case,
> I still see a reason for special casing, possibly even nicely
> #ifdef'ed , not causing any penalty on "-ffloat-store" or
> x86_64 platforms ?
>
> (*) Our 99.x % of R users would lack too much background
>context to understand the problem even when urged to "learn"
>about it in some way. They will always blame R in s
[Rd] Rcpp and dot in package name
I have run across a problem with Rcpp and trying to create a package
with a name containing a dot ('.') using Rcpp.package.skeleton. I get
the following error
RcppExports.cpp:10:25: error: expected initializer before '.' token
RcppExport SEXP genetics.haplotype_rcpp_hello_world() {
implying that Rcpp literally uses the package name in internal function
name generation. Unfortunately, if I use an underscore ('_') instead, I get
Error : Invalid DESCRIPTION file
Malformed package name
See the information on DESCRIPTION files in section 'Creating R
packages' of the 'Writing R Extensions' manual.
Is there a workaround known?
Thanks in advance,
Stefan
--
http://s-boehringer.org
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Rcpp and dot in package name
Stefan, R-devel is the wrong list. Please subscribe to rcpp-devel and ask there. Short tip: Don't use a dot in the name. See the 260+ packages depending on Rcpp listed at the bottom of eg http://cran.rstudio.com/web/packages/Rcpp/index.html -- I essentially see no dot there. Regards, Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] timings for examples in R CMD check
I'm having a very hard time making R CMD check produce a clean check on
examples because of the timings inserted into examples by R CMD check.
I am getting a difference on every example output caused by timing
information being inserted by 'R CMD check'.
The current 'Writing R Extensions' manual[1] states on p. 14:
If directory tests has a subdirectory Examples containing a
file pkg-Ex.Rout.save, this is compared to the output file
for running the examples when the latter are checked.
Reference output should be produced without having the
--timings option set (and note that --as-cran sets it).
As is suggested above, if I run
R CMD check --as-cran mypkg.tar.gz
or
R CMD check --timings mypkg.tar.gz
the my.pkg.Rcheck/mypkg-Ex.Rout file contains timing lines inserted by
'R CMD check'
If, instead, I follow my reading of the manual, and run
R CMD check mypkg.tar.gz
the mypkg.Rcheck/mypkg-Ex.Rout file does not contain timings. If I then
copy the mypkg.Rcheck/mypkg-Ex.Rout file to
mypkg/tests/Examples/mypkg-Ex.Rout.save
as described by footnote 17 on the previously referenced p. 14, I would
expect to now have no differences, as demonstrated by 'diff' or 'diff
-bw' as used by 'R CMD check'.
To my surprise, whether I copy a version of the mypkg-Ex.Rout file with
or without timing rows, I get differences reported for every example by
the (spurious?) insertion of timings by R CMD check.
e.g.
8169a8549,8550
> > base::assign(".dptime", (proc.time() - get(".ptime", pos =
"CheckExEnv")), pos = "CheckExEnv")
> > base::cat("textplot", base::get(".format_ptime", pos =
'CheckExEnv')(get(".dptime", pos = "CheckExEnv")), "\n",
file=base::get(".ExTimings", pos = 'CheckExEnv'), append=TRUE, sep="\t")
8175a8557
Is this expected?
It is certainly not the behavior we had for many years, where a check of
examples could actually be clean, producing differences only on the
'Time elapsed:' line, which has been present for many R versions. I
have tried testing against a package with both the timing lines includes
and excluded in /mypkg-Ex.Rout.save, and with R CMD check run without
additional options, with --timings, and with --as-cran. They produce
equivalent check files. on their example checks.
This behavior is on R 3.1.0, 3.1.1, and R-devel.
I would assume from the documentation that there should be a way to get
a clean check, without the timing diffs.
Advice appreciated,
Brian
Ref:
[1] http://cran.r-project.org/doc/manuals/R-exts.pdf
--
Brian G. Peterson
http://braverock.com/brian/
Ph: 773-459-4973
IM: bgpbraverock
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] timings for examples in R CMD check
I did not really try it, but perhaps setting _R_CHECK_TIMINGS_=false
in your ~/.Renviron works?
http://cran.rstudio.com/doc/manuals/r-release/R-ints.html#Tools
Regards,
Yihui
--
Yihui Xie
Web: http://yihui.name
On Wed, Sep 3, 2014 at 2:58 PM, Brian G. Peterson wrote:
> I'm having a very hard time making R CMD check produce a clean check on
> examples because of the timings inserted into examples by R CMD check.
>
> I am getting a difference on every example output caused by timing
> information being inserted by 'R CMD check'.
>
> The current 'Writing R Extensions' manual[1] states on p. 14:
>
>If directory tests has a subdirectory Examples containing a
>file pkg-Ex.Rout.save, this is compared to the output file
>for running the examples when the latter are checked.
>Reference output should be produced without having the
>--timings option set (and note that --as-cran sets it).
>
> As is suggested above, if I run
>
>R CMD check --as-cran mypkg.tar.gz
>
> or
>
>R CMD check --timings mypkg.tar.gz
>
> the my.pkg.Rcheck/mypkg-Ex.Rout file contains timing lines inserted by 'R
> CMD check'
>
> If, instead, I follow my reading of the manual, and run
>
> R CMD check mypkg.tar.gz
>
> the mypkg.Rcheck/mypkg-Ex.Rout file does not contain timings. If I then
> copy the mypkg.Rcheck/mypkg-Ex.Rout file to
>
> mypkg/tests/Examples/mypkg-Ex.Rout.save
>
> as described by footnote 17 on the previously referenced p. 14, I would
> expect to now have no differences, as demonstrated by 'diff' or 'diff -bw'
> as used by 'R CMD check'.
>
> To my surprise, whether I copy a version of the mypkg-Ex.Rout file with or
> without timing rows, I get differences reported for every example by the
> (spurious?) insertion of timings by R CMD check.
>
> e.g.
> 8169a8549,8550
>> > base::assign(".dptime", (proc.time() - get(".ptime", pos =
>> > "CheckExEnv")), pos = "CheckExEnv")
>> > base::cat("textplot", base::get(".format_ptime", pos =
>> > 'CheckExEnv')(get(".dptime", pos = "CheckExEnv")), "\n",
>> > file=base::get(".ExTimings", pos = 'CheckExEnv'), append=TRUE, sep="\t")
> 8175a8557
>
>
>
> Is this expected?
>
> It is certainly not the behavior we had for many years, where a check of
> examples could actually be clean, producing differences only on the 'Time
> elapsed:' line, which has been present for many R versions. I have tried
> testing against a package with both the timing lines includes and excluded
> in /mypkg-Ex.Rout.save, and with R CMD check run without additional options,
> with --timings, and with --as-cran. They produce equivalent check files.
> on their example checks.
>
> This behavior is on R 3.1.0, 3.1.1, and R-devel.
>
> I would assume from the documentation that there should be a way to get a
> clean check, without the timing diffs.
>
> Advice appreciated,
>
> Brian
>
> Ref:
> [1] http://cran.r-project.org/doc/manuals/R-exts.pdf
>
> --
> Brian G. Peterson
> http://braverock.com/brian/
> Ph: 773-459-4973
> IM: bgpbraverock
>
> __
> 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] timings for examples in R CMD check
Brian,
What you are doing is how I have always checked my packages:
1. Run R CMD check pkg_tarball.tar.gz
2. mv pkg.Rcheck/pkg-Ex.Rout pkg_sources/tests/Examples/pkg-Ex.Rout.save
3. Next R CMD check pkg_tarball.tar.gz checks against the new Example output
Are you sure you are getting the newly created pkg-Ex.Rout file and placing
it in the correct part of the package and adjusting the name
to pkg-Ex.Rout.save?
The only time I ever had a problem with this was when I inadvertently used
a .Rout file from a check with --as-cran.
G
On 3 September 2014 13:58, Brian G. Peterson wrote:
> I'm having a very hard time making R CMD check produce a clean check on
> examples because of the timings inserted into examples by R CMD check.
>
> I am getting a difference on every example output caused by timing
> information being inserted by 'R CMD check'.
>
> The current 'Writing R Extensions' manual[1] states on p. 14:
>
>If directory tests has a subdirectory Examples containing a
>file pkg-Ex.Rout.save, this is compared to the output file
>for running the examples when the latter are checked.
>Reference output should be produced without having the
>--timings option set (and note that --as-cran sets it).
>
> As is suggested above, if I run
>
>R CMD check --as-cran mypkg.tar.gz
>
> or
>
>R CMD check --timings mypkg.tar.gz
>
> the my.pkg.Rcheck/mypkg-Ex.Rout file contains timing lines inserted by 'R
> CMD check'
>
> If, instead, I follow my reading of the manual, and run
>
> R CMD check mypkg.tar.gz
>
> the mypkg.Rcheck/mypkg-Ex.Rout file does not contain timings. If I then
> copy the mypkg.Rcheck/mypkg-Ex.Rout file to
>
> mypkg/tests/Examples/mypkg-Ex.Rout.save
>
> as described by footnote 17 on the previously referenced p. 14, I would
> expect to now have no differences, as demonstrated by 'diff' or 'diff -bw'
> as used by 'R CMD check'.
>
> To my surprise, whether I copy a version of the mypkg-Ex.Rout file with or
> without timing rows, I get differences reported for every example by the
> (spurious?) insertion of timings by R CMD check.
>
> e.g.
> 8169a8549,8550
> > > base::assign(".dptime", (proc.time() - get(".ptime", pos =
> "CheckExEnv")), pos = "CheckExEnv")
> > > base::cat("textplot", base::get(".format_ptime", pos =
> 'CheckExEnv')(get(".dptime", pos = "CheckExEnv")), "\n",
> file=base::get(".ExTimings", pos = 'CheckExEnv'), append=TRUE, sep="\t")
> 8175a8557
>
>
>
> Is this expected?
>
> It is certainly not the behavior we had for many years, where a check of
> examples could actually be clean, producing differences only on the 'Time
> elapsed:' line, which has been present for many R versions. I have tried
> testing against a package with both the timing lines includes and excluded
> in /mypkg-Ex.Rout.save, and with R CMD check run without additional
> options, with --timings, and with --as-cran. They produce equivalent
> check files. on their example checks.
>
> This behavior is on R 3.1.0, 3.1.1, and R-devel.
>
> I would assume from the documentation that there should be a way to get a
> clean check, without the timing diffs.
>
> Advice appreciated,
>
> Brian
>
> Ref:
> [1] http://cran.r-project.org/doc/manuals/R-exts.pdf
>
> --
> Brian G. Peterson
> http://braverock.com/brian/
> Ph: 773-459-4973
> IM: bgpbraverock
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Gavin Simpson, PhD
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] timings for examples in R CMD check
Gavin,
You were correct. Operator error.
My tests/Examples directory contained both a
‘PerformanceAnalytics-Ex.Rout’ and a
‘PerformanceAnalytics-Ex.Rout.save’
file.
Corrected now, and check shows
* checking examples ... OK
Thanks for the help.
Brian
On 09/03/2014 03:36 PM, Gavin Simpson wrote:
Brian,
What you are doing is how I have always checked my packages:
1. Run R CMD check pkg_tarball.tar.gz
2. mv pkg.Rcheck/pkg-Ex.Rout pkg_sources/tests/Examples/pkg-Ex.Rout.save
3. Next R CMD check pkg_tarball.tar.gz checks against the new Example output
Are you sure you are getting the newly created pkg-Ex.Rout file and
placing it in the correct part of the package and adjusting the name
to pkg-Ex.Rout.save?
The only time I ever had a problem with this was when I inadvertently
used a .Rout file from a check with --as-cran.
G
On 3 September 2014 13:58, Brian G. Peterson mailto:br...@braverock.com>> wrote:
I'm having a very hard time making R CMD check produce a clean check
on examples because of the timings inserted into examples by R CMD
check.
I am getting a difference on every example output caused by timing
information being inserted by 'R CMD check'.
The current 'Writing R Extensions' manual[1] states on p. 14:
If directory tests has a subdirectory Examples containing a
file pkg-Ex.Rout.save, this is compared to the output file
for running the examples when the latter are checked.
Reference output should be produced without having the
--timings option set (and note that --as-cran sets it).
As is suggested above, if I run
R CMD check --as-cran mypkg.tar.gz
or
R CMD check --timings mypkg.tar.gz
the my.pkg.Rcheck/mypkg-Ex.Rout file contains timing lines inserted
by 'R CMD check'
If, instead, I follow my reading of the manual, and run
R CMD check mypkg.tar.gz
the mypkg.Rcheck/mypkg-Ex.Rout file does not contain timings. If I
then copy the mypkg.Rcheck/mypkg-Ex.Rout file to
mypkg/tests/Examples/mypkg-Ex.__Rout.save
as described by footnote 17 on the previously referenced p. 14, I
would expect to now have no differences, as demonstrated by 'diff'
or 'diff -bw' as used by 'R CMD check'.
To my surprise, whether I copy a version of the mypkg-Ex.Rout file
with or without timing rows, I get differences reported for every
example by the (spurious?) insertion of timings by R CMD check.
e.g.
8169a8549,8550
> > base::assign(".dptime", (proc.time() - get(".ptime", pos =
"CheckExEnv")), pos = "CheckExEnv")
> > base::cat("textplot", base::get(".format_ptime", pos =
'CheckExEnv')(get(".dptime", pos = "CheckExEnv")), "\n",
file=base::get(".ExTimings", pos = 'CheckExEnv'), append=TRUE, sep="\t")
8175a8557
Is this expected?
It is certainly not the behavior we had for many years, where a
check of examples could actually be clean, producing differences
only on the 'Time elapsed:' line, which has been present for many R
versions. I have tried testing against a package with both the
timing lines includes and excluded in /mypkg-Ex.Rout.save, and with
R CMD check run without additional options, with --timings, and with
--as-cran. They produce equivalent check files. on their example
checks.
This behavior is on R 3.1.0, 3.1.1, and R-devel.
I would assume from the documentation that there should be a way to
get a clean check, without the timing diffs.
Advice appreciated,
Brian
Ref:
[1] http://cran.r-project.org/doc/__manuals/R-exts.pdf
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] 'library(ggplot2)' R CMD check WARNING in vignette R code
Hi, can I claim the warning that occurs (at R CMD check --as-cran) when I use 'library(ggplot2)' in executed vignette code as SPURIOUS (as mentioned in the CRAN policies at section 'Submission') and (since it is the only warning/error) get my package submission accepted? Has anybody experience with that? Otherwise, is there a workaround to evaluate this code (and calls to ggplot()) in a vignette for a CRAN package? Thank you, Sven. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 'library(ggplot2)' R CMD check WARNING in vignette R code
On 04.09.2014 01:03, Sven E. Templer wrote: Hi, can I claim the warning that occurs (at R CMD check --as-cran) when I use 'library(ggplot2)' in executed vignette code as SPURIOUS (as mentioned in the CRAN policies at section 'Submission') and (since it is the only warning/error) get my package submission accepted? Has anybody experience with that? Otherwise, is there a workaround to evaluate this code (and calls to ggplot()) in a vignette for a CRAN package? We don't know what the waring is, hence hard to help. My guess is you forgot to declare a dependency such as "Suggestes" on ggplot2. Best, Uwe Ligges Thank you, Sven. __ 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] 'library(ggplot2)' R CMD check WARNING in vignette R code
This guess solved the issue, thank you! Sven On 4 September 2014 01:16, Uwe Ligges wrote: > > > On 04.09.2014 01:03, Sven E. Templer wrote: >> >> Hi, >> >> can I claim the warning that occurs (at R CMD check --as-cran) when I >> use 'library(ggplot2)' in executed vignette code as SPURIOUS (as >> mentioned in the CRAN policies at section 'Submission') and (since it >> is the only warning/error) get my package submission accepted? Has >> anybody experience with that? Otherwise, is there a workaround to >> evaluate this code (and calls to ggplot()) in a vignette for a CRAN >> package? > > > We don't know what the waring is, hence hard to help. My guess is you forgot > to declare a dependency such as "Suggestes" on ggplot2. > > Best, > Uwe Ligges > > > >> >> Thank you, >> Sven. >> >> __ >> 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
