Re: [Rd] R 3.1.1 and 3.1.2 both fail their test suites
On 05/11/2014 9:36 AM, Peter Simons wrote:
Hi Duncan,
> I don't think we should be removing tests for everybody to allow a few
> people to test a build of R that none of us actually use.
no tests need to be removed.
My response was to Martin, who proposed exactly that.
All that needs to be done is to distinguish
tests that require the recommended packages from those that don't. Then
users can choose which test set they want to run.
Go ahead and submit a patch that does this, and I expect it would be
accepted.
Duncan Murdoch
It would be particularly nice if "make check" would do the right thing
automatically based on the choice of --with{,out}-recommended-packages
at ./configure time. Offering two separate "check" targets would be
equally good, though.
Best regards,
Peter
__
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] Linking to the BH package introduces CRAN warnings
> Le 5 nov. 2014 à 14:45, Dirk Eddelbuettel a écrit : > > > On 5 November 2014 at 14:11, Romain Francois wrote: > | > Le 5 nov. 2014 à 13:43, Dirk Eddelbuettel a écrit : > | > You are NOT forced or required to use the Boost distributions header __as > R > | > comes with the equivalent functionality__ via the Rmath.h header file > from R. > | > Which has functionality that Rcpp provides to you in scalar and vector > form. > | > > | > And there are probably several dozen examples of using the R distribution > | > functions from Rcpp. > | > > | > So this is _precisely_ what I suggested several mails ago: do your > homework, > | > identify which header is causing it. And the obvious next step is then to > | > not use the header. > | > | So why these headers are shipped with BH then. > > The BH "builder" (ie the script local/scripts/CreateBoost.sh in the repo) > actively selects a number of Boost libraries [1], and uses the Boost tool > 'bcp' to copy these (header-only) libraries -- plus all their dependencies. > The set of "selected components" grew out of initial requirements, plus > requests received since the package was created. [2] > > Now, just because some files within a library tickle a warning does not seem > to imply that all use of said warning is impossible. By my count, over two > dozen CRAN packages currently depend on BH [3] indicating some usefulness of > BH, > including to the dplyr package you work on. Yeah so that’s like « we’ll sell you horticultural bulbs, but only use them for indoor culture of tomatoes, ‘cause you know it’s illegal to grow weed » whatever. Believe me, I’d love for dplyr not to depend on BH, which we use for unordered_map. > Policies and requirements do of cause charge, but I am not aware of any of > the two dozen package tickling this issue -- their use case is just fine, > thank you, and their requirements lead to the inclusion of the header > currently comprised in the package. > > I hope this answers your question. Should you have further questions > concerning the BH package, could you be so kind as to bringing them to > appropriate list [4] or filing a ticket on GH? This was not really a question, so yes I guess it answers it. Not your fault, just the user’s fault of using something that is shipped yet is unusable. You’re in the clear. > Thanks, Dirk > > [1] "components" may be a better term so we avoid the association with > "linking" > [2] Another one of these requests just came in this week asking for > circular_buffer. > [3] http://cran.r-project.org/web/packages/BH/index.html > [4] > http://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/boostheaders-devel > > -- > http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 3.1.1 and 3.1.2 both fail their test suites
Hi Duncan,
> I don't think we should be removing tests for everybody to allow a few
> people to test a build of R that none of us actually use.
no tests need to be removed. All that needs to be done is to distinguish
tests that require the recommended packages from those that don't. Then
users can choose which test set they want to run.
It would be particularly nice if "make check" would do the right thing
automatically based on the choice of --with{,out}-recommended-packages
at ./configure time. Offering two separate "check" targets would be
equally good, though.
Best regards,
Peter
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Linking to the BH package introduces CRAN warnings
On 5 November 2014 at 14:11, Romain Francois wrote: | > Le 5 nov. 2014 à 13:43, Dirk Eddelbuettel a écrit : | > You are NOT forced or required to use the Boost distributions header __as R | > comes with the equivalent functionality__ via the Rmath.h header file from R. | > Which has functionality that Rcpp provides to you in scalar and vector form. | > | > And there are probably several dozen examples of using the R distribution | > functions from Rcpp. | > | > So this is _precisely_ what I suggested several mails ago: do your homework, | > identify which header is causing it. And the obvious next step is then to | > not use the header. | | So why these headers are shipped with BH then. The BH "builder" (ie the script local/scripts/CreateBoost.sh in the repo) actively selects a number of Boost libraries [1], and uses the Boost tool 'bcp' to copy these (header-only) libraries -- plus all their dependencies. The set of "selected components" grew out of initial requirements, plus requests received since the package was created. [2] Now, just because some files within a library tickle a warning does not seem to imply that all use of said warning is impossible. By my count, over two dozen CRAN packages currently depend on BH [3] indicating some usefulness of BH, including to the dplyr package you work on. Policies and requirements do of cause charge, but I am not aware of any of the two dozen package tickling this issue -- their use case is just fine, thank you, and their requirements lead to the inclusion of the header currently comprised in the package. I hope this answers your question. Should you have further questions concerning the BH package, could you be so kind as to bringing them to appropriate list [4] or filing a ticket on GH? Thanks, Dirk [1] "components" may be a better term so we avoid the association with "linking" [2] Another one of these requests just came in this week asking for circular_buffer. [3] http://cran.r-project.org/web/packages/BH/index.html [4] http://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/boostheaders-devel -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Linking to the BH package introduces CRAN warnings
On 5 November 2014 at 13:54, kaveh wrote: | Dear, | | I was expecting this reaction. | | Please do not get caught up in the details of the examples, | which I have tried to make as simple as possible for your | benefit. Well, to be perfectly honst, there you failed. No need to carry RcppEigen for example. "Minimally reproducible" is how describe ideal examples. | The main point is that if you remove the lines associated | with | | boost/math/distributions/ | | | the warning disappears as well. Ergo, | | boost/math/distributions/ | | is causing the warnings. Yes, and I suggested to you to remove these lines, and offered you an easy alternative already provided by the R system in which you are trying to craft your extension. I mentioned in my first email that I thought your post was probably off-topic for r-devel. You have now posted six more times to this list. I would urge to consider if it really the most appropropriate venue for this. Hope this helps, Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Linking to the BH package introduces CRAN warnings
Envoyé de mon iPhone
> Le 5 nov. 2014 à 13:43, Dirk Eddelbuettel a écrit :
>
>
> On 5 November 2014 at 00:55, kaveh wrote:
> | Dear all,
> |
> |
> | the simple code in below, when send to the
> | win-builder returns the following (and no other)
> | warning:
> |
> |
> | * checking compiled code ... WARNING
> | File 'quicky/libs/i386/quicky.dll':
> |Found '_ZSt4cerr', possibly from 'std::cerr' (C++)
> | Object: 'quicky.o'
> |Found 'abort', possibly from 'abort' (C), 'runtime' (Fortran)
> | Object: 'quicky.o'
> | File 'quicky/libs/x64/quicky.dll':
> |Found '_ZSt4cerr', possibly from 'std::cerr' (C++)
> | Object: 'quicky.o'
> |Found 'abort', possibly from 'abort' (C), 'runtime' (Fortran)
> | Object: 'quicky.o'
> |
> | Compiled code should not call entry points which might terminate R nor
> | write to stdout/stderr instead of to the console, nor the C RNG.
> |
> | See 'Writing portable packages' in the 'Writing R Extensions' manual.
> |
> |
> | Here is the source:
> |
> | #include
> | #include
> | #include
> | #include
> | #include
> | #include
> | #include
> | #include
> | #include
> | #include
> | #include
> | #include
> | #include
> |
> | #include
> | #include
> |
> | #include
> |
> | using namespace std;
> | using namespace Eigen;
> | using Eigen::MatrixXd;
> | using Eigen::VectorXd;
> | using Eigen::VectorXi;
> | using Eigen::RowVectorXd;
> |
> |
> | using boost::math::chi_squared;
> | using boost::math::quantile;
> | using boost::math::complement;
> | using boost::math::normal_distribution;
> | using namespace boost::math::policies;
> |
> | typedef policy<
> |promote_double
> |> my_policy_norm;
> | typedef policy<
> |promote_double
> |> my_policy_chi2;
> |
> | typedef boost::math::normal_distribution my_norm;
> | typedef boost::math::chi_squared_distribution
> | my_chi2;
> |
> |
> | VectorXd GetQs(const VectorXd& x){
> | const int n=x.size();
> | double mytol=1e-8;
> | double the_max=x.maxCoeff();
> | double the_min=x.minCoeff();
> | double the_rag=(the_max-the_min);
> | if(the_rag | if(1.0-the_max | if(the_min | VectorXd y=x.array();
> | for(int i=0;i | y(i)=sqrt(quantile(complement(my_chi2(1.0),x(i;
> | return(y);
> | }
> | extern "C"{
> | void quicky(int* rn,double* xi,double* yi){
> | const int n=*rn;
> | VectorXd x=Map(xi,n);
> | Map(yi,n)=GetQs(x);
> | }
> | }
> |
> |
> | So I guess, I should fill a bug report with the
> | BH maintainer?
>
> Err, why? BH does nothing wrong.
Calls to these forbidden fruits come from the BH tree so ...
> You are NOT forced or required to use the Boost distributions header __as R
> comes with the equivalent functionality__ via the Rmath.h header file from R.
> Which has functionality that Rcpp provides to you in scalar and vector form.
>
> And there are probably several dozen examples of using the R distribution
> functions from Rcpp.
>
> So this is _precisely_ what I suggested several mails ago: do your homework,
> identify which header is causing it. And the obvious next step is then to
> not use the header.
So why these headers are shipped with BH then.
> Dirk
>
>
> | Best regards,
> |
> |
> | On 2014-11-04 23:52, Dirk Eddelbuettel wrote:
> | > Gentlemen,
> | >
> | > On 4 November 2014 at 23:36, kaveh wrote:
> | > | Dear Hadley,
> | > |
> | > | Thank you for this information, maybe the CRAN gods
> | > | will look favourably on this case too,
> | >
> | > You seemed to have missed a point my earlier email tried to stress:
> Inclusion
> | > of BH does not lead to the warning.
> | >
> | > All this depends on WHICH headers are included, and the OP will need to
> sort
> | > this out by modifying his code.
> | >
> | > Dirk
> | >
> | > | Best regards,
> | > |
> | > | On 2014-11-04 23:32, Hadley Wickham wrote:
> | > | >>> | However, it seems some of the codes in the BH package
> | > | >>> | might. At any rate, when I include some boost headers such as
> | > | >>> | boost/math/distributions/ through BH, I get the following warnings
> | > | >>> | when submitting to the win-builder page:
> | > | >>> |
> | > | >>> |
> | > | >>> |Found '_ZSt4cerr', possibly from 'std::cerr' (C++)
> | > | >>> |
> | > | >>> |Found 'abort', possibly from 'abort' (C), 'runtime' (Fortran)
> | > | >>> |
> | > | >>> |Found '_ZSt4cerr', possibly from 'std::cerr' (C++)
> | > | >>> |
> | > | >>> |Found 'abort', possibly from 'abort' (C), 'runtime' (Fortran)
> | > | >> You’re kind of out of luck. These functions are both:
> | > | >> - used by the boost headers
> | > | >> - forbidden by R, well at least forbidden by CRAN
> | > | > Mybe - I had this note in RSQLite, and CRAN seemed ok with my
> explanation:
> | > | >
> | > | > * checking compiled code ... NOTE
> | > | >File
> ‘/Users/hadley/Documents/databases/RSQLite.Rcheck/RSQLite/libs/RSQLite.so’:
> |
Re: [Rd] R 3.1.1 and 3.1.2 both fail their test suites
On 05 Nov 2014, at 13:12 , Duncan Murdoch wrote: > > I don't think we should be removing tests for everybody to allow a few > people to test a build of R that none of us actually use. Yes. Having R pass "make check" while breaking recommended packages would be unfortunate. I wouldn't object to special variations like "make check-without-recommended" or "make check-core". Except, of course, if the dontrun/dontcheck logic gets even more convoluted than it already is... -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Linking to the BH package introduces CRAN warnings
Dear,
I was expecting this reaction.
Please do not get caught up in the details of the examples,
which I have tried to make as simple as possible for your
benefit.
The main point is that if you remove the lines associated
with
boost/math/distributions/
the warning disappears as well. Ergo,
boost/math/distributions/
is causing the warnings.
Best regards,
On 2014-11-05 13:43, Dirk Eddelbuettel wrote:
On 5 November 2014 at 00:55, kaveh wrote:
| Dear all,
|
|
| the simple code in below, when send to the
| win-builder returns the following (and no other)
| warning:
|
|
| * checking compiled code ... WARNING
| File 'quicky/libs/i386/quicky.dll':
|Found '_ZSt4cerr', possibly from 'std::cerr' (C++)
| Object: 'quicky.o'
|Found 'abort', possibly from 'abort' (C), 'runtime' (Fortran)
| Object: 'quicky.o'
| File 'quicky/libs/x64/quicky.dll':
|Found '_ZSt4cerr', possibly from 'std::cerr' (C++)
| Object: 'quicky.o'
|Found 'abort', possibly from 'abort' (C), 'runtime' (Fortran)
| Object: 'quicky.o'
|
| Compiled code should not call entry points which might terminate R nor
| write to stdout/stderr instead of to the console, nor the C RNG.
|
| See 'Writing portable packages' in the 'Writing R Extensions' manual.
|
|
| Here is the source:
|
| #include
| #include
| #include
| #include
| #include
| #include
| #include
| #include
| #include
| #include
| #include
| #include
| #include
|
| #include
| #include
|
| #include
|
| using namespace std;
| using namespace Eigen;
| using Eigen::MatrixXd;
| using Eigen::VectorXd;
| using Eigen::VectorXi;
| using Eigen::RowVectorXd;
|
|
| using boost::math::chi_squared;
| using boost::math::quantile;
| using boost::math::complement;
| using boost::math::normal_distribution;
| using namespace boost::math::policies;
|
| typedef policy<
|promote_double
|> my_policy_norm;
| typedef policy<
|promote_double
|> my_policy_chi2;
|
| typedef boost::math::normal_distribution my_norm;
| typedef boost::math::chi_squared_distribution
| my_chi2;
|
|
| VectorXd GetQs(const VectorXd& x){
| const int n=x.size();
| double mytol=1e-8;
| double the_max=x.maxCoeff();
| double the_min=x.minCoeff();
| double the_rag=(the_max-the_min);
| if(the_rag(xi,n);
| Map(yi,n)=GetQs(x);
| }
| }
|
|
| So I guess, I should fill a bug report with the
| BH maintainer?
Err, why? BH does nothing wrong.
You are NOT forced or required to use the Boost distributions header __as R
comes with the equivalent functionality__ via the Rmath.h header file from R.
Which has functionality that Rcpp provides to you in scalar and vector form.
And there are probably several dozen examples of using the R distribution
functions from Rcpp.
So this is _precisely_ what I suggested several mails ago: do your homework,
identify which header is causing it. And the obvious next step is then to
not use the header.
Dirk
| Best regards,
|
|
| On 2014-11-04 23:52, Dirk Eddelbuettel wrote:
| > Gentlemen,
| >
| > On 4 November 2014 at 23:36, kaveh wrote:
| > | Dear Hadley,
| > |
| > | Thank you for this information, maybe the CRAN gods
| > | will look favourably on this case too,
| >
| > You seemed to have missed a point my earlier email tried to stress:
Inclusion
| > of BH does not lead to the warning.
| >
| > All this depends on WHICH headers are included, and the OP will need to sort
| > this out by modifying his code.
| >
| > Dirk
| >
| > | Best regards,
| > |
| > | On 2014-11-04 23:32, Hadley Wickham wrote:
| > | >>> | However, it seems some of the codes in the BH package
| > | >>> | might. At any rate, when I include some boost headers such as
| > | >>> | boost/math/distributions/ through BH, I get the following warnings
| > | >>> | when submitting to the win-builder page:
| > | >>> |
| > | >>> |
| > | >>> |Found '_ZSt4cerr', possibly from 'std::cerr' (C++)
| > | >>> |
| > | >>> |Found 'abort', possibly from 'abort' (C), 'runtime' (Fortran)
| > | >>> |
| > | >>> |Found '_ZSt4cerr', possibly from 'std::cerr' (C++)
| > | >>> |
| > | >>> |Found 'abort', possibly from 'abort' (C), 'runtime' (Fortran)
| > | >> You’re kind of out of luck. These functions are both:
| > | >> - used by the boost headers
| > | >> - forbidden by R, well at least forbidden by CRAN
| > | > Mybe - I had this note in RSQLite, and CRAN seemed ok with my
explanation:
| > | >
| > | > * checking compiled code ... NOTE
| > | >File
‘/Users/hadley/Documents/databases/RSQLite.Rcheck/RSQLite/libs/RSQLite.so’:
| > | > Found ‘___stderrp’, possibly from ‘stderr’ (C)
| > | >Object: ‘sqlite-all.o’
| > | >
| > | >This is in C code from the embedded SQLite database.
| > | >
| > | >
| > | > Hadley
| > | >
| > |
| >
|
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Linking to the BH package introduces CRAN warnings
On 5 November 2014 at 00:55, kaveh wrote:
| Dear all,
|
|
| the simple code in below, when send to the
| win-builder returns the following (and no other)
| warning:
|
|
| * checking compiled code ... WARNING
| File 'quicky/libs/i386/quicky.dll':
|Found '_ZSt4cerr', possibly from 'std::cerr' (C++)
| Object: 'quicky.o'
|Found 'abort', possibly from 'abort' (C), 'runtime' (Fortran)
| Object: 'quicky.o'
| File 'quicky/libs/x64/quicky.dll':
|Found '_ZSt4cerr', possibly from 'std::cerr' (C++)
| Object: 'quicky.o'
|Found 'abort', possibly from 'abort' (C), 'runtime' (Fortran)
| Object: 'quicky.o'
|
| Compiled code should not call entry points which might terminate R nor
| write to stdout/stderr instead of to the console, nor the C RNG.
|
| See 'Writing portable packages' in the 'Writing R Extensions' manual.
|
|
| Here is the source:
|
| #include
| #include
| #include
| #include
| #include
| #include
| #include
| #include
| #include
| #include
| #include
| #include
| #include
|
| #include
| #include
|
| #include
|
| using namespace std;
| using namespace Eigen;
| using Eigen::MatrixXd;
| using Eigen::VectorXd;
| using Eigen::VectorXi;
| using Eigen::RowVectorXd;
|
|
| using boost::math::chi_squared;
| using boost::math::quantile;
| using boost::math::complement;
| using boost::math::normal_distribution;
| using namespace boost::math::policies;
|
| typedef policy<
|promote_double
|> my_policy_norm;
| typedef policy<
|promote_double
|> my_policy_chi2;
|
| typedef boost::math::normal_distribution my_norm;
| typedef boost::math::chi_squared_distribution
| my_chi2;
|
|
| VectorXd GetQs(const VectorXd& x){
| const int n=x.size();
| double mytol=1e-8;
| double the_max=x.maxCoeff();
| double the_min=x.minCoeff();
| double the_rag=(the_max-the_min);
| if(the_rag(xi,n);
| Map(yi,n)=GetQs(x);
| }
| }
|
|
| So I guess, I should fill a bug report with the
| BH maintainer?
Err, why? BH does nothing wrong.
You are NOT forced or required to use the Boost distributions header __as R
comes with the equivalent functionality__ via the Rmath.h header file from R.
Which has functionality that Rcpp provides to you in scalar and vector form.
And there are probably several dozen examples of using the R distribution
functions from Rcpp.
So this is _precisely_ what I suggested several mails ago: do your homework,
identify which header is causing it. And the obvious next step is then to
not use the header.
Dirk
| Best regards,
|
|
| On 2014-11-04 23:52, Dirk Eddelbuettel wrote:
| > Gentlemen,
| >
| > On 4 November 2014 at 23:36, kaveh wrote:
| > | Dear Hadley,
| > |
| > | Thank you for this information, maybe the CRAN gods
| > | will look favourably on this case too,
| >
| > You seemed to have missed a point my earlier email tried to stress:
Inclusion
| > of BH does not lead to the warning.
| >
| > All this depends on WHICH headers are included, and the OP will need to sort
| > this out by modifying his code.
| >
| > Dirk
| >
| > | Best regards,
| > |
| > | On 2014-11-04 23:32, Hadley Wickham wrote:
| > | >>> | However, it seems some of the codes in the BH package
| > | >>> | might. At any rate, when I include some boost headers such as
| > | >>> | boost/math/distributions/ through BH, I get the following warnings
| > | >>> | when submitting to the win-builder page:
| > | >>> |
| > | >>> |
| > | >>> |Found '_ZSt4cerr', possibly from 'std::cerr' (C++)
| > | >>> |
| > | >>> |Found 'abort', possibly from 'abort' (C), 'runtime' (Fortran)
| > | >>> |
| > | >>> |Found '_ZSt4cerr', possibly from 'std::cerr' (C++)
| > | >>> |
| > | >>> |Found 'abort', possibly from 'abort' (C), 'runtime' (Fortran)
| > | >> You’re kind of out of luck. These functions are both:
| > | >> - used by the boost headers
| > | >> - forbidden by R, well at least forbidden by CRAN
| > | > Mybe - I had this note in RSQLite, and CRAN seemed ok with my
explanation:
| > | >
| > | > * checking compiled code ... NOTE
| > | >File
‘/Users/hadley/Documents/databases/RSQLite.Rcheck/RSQLite/libs/RSQLite.so’:
| > | > Found ‘___stderrp’, possibly from ‘stderr’ (C)
| > | >Object: ‘sqlite-all.o’
| > | >
| > | >This is in C code from the embedded SQLite database.
| > | >
| > | >
| > | > Hadley
| > | >
| > |
| >
|
--
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 3.1.1 and 3.1.2 both fail their test suites
On 05/11/2014, 6:48 AM, Martin Maechler wrote:
>> Duncan Murdoch
>> on Mon, 3 Nov 2014 06:28:19 -0500 writes:
>
> > On 03/11/2014, 4:17 AM, Martin Maechler wrote:
> >>> Duncan Murdoch
> >>> on Sat, 1 Nov 2014 13:17:56 -0400 writes:
> >>
> >> > On 01/11/2014, 11:33 AM, Peter Simons wrote:
> >> >> Hi Uwe,
> >> >>
> >> >> > Nobody in R core runs NixOS and can reproduce
> >> >> this. This passes on most > other platforms,
> >> >> apparently. If you can point us to a problem or send >
> >> >> patches, we'd appreciate it.
> >> >>
> >> >> have tried running the test suite in a build that's
> >> >> configured with '--without-recommended-packages'? That's
> >> >> about the only unusual thing we do when building with
> >> >> Nix. Other than that, our build runs on a perfectly
> >> >> ordinary Linux -- and it used to succeed fine in earlier
> >> >> versions of R.
> >>
> >> > The tests "make check-devel" and "make check-all" are
> >> > documented to require the recommended packages, and will
> >> > fail without them. On Windows, "make check" also needs
> >> > them, so this may be true on other systems as well.
> >>
> >> Thank you Duncan, for clarifying (above and later in the thread).
> >>
> >> Would it be hard to strive for
> >>
> >> 1) 'make check' should pass without-rec
> >> 2) 'make check-devel' etc do require the recommended packages.
> >>
> >> That would be ideal I think - and correspond to the fact that
> >> we call the recommended packages 'recommended' only.
>
> > I think we could avoid errors in make check, but not warnings. People
> > need to understand what the tests are testing, and recognize that some
> > warnings are ignorable.
>
> > To do this, we'd need to make sure that no examples in base packages
> > require the use of recommended packages. Currently the failure happens
> > in capture.output, because it runs the glm example which needs MASS.
> > (The glm example is marked not to need MASS during testing, but the
> > capture.output example runs everything.)
>
> aah.. that's interesting in itself: Maybe example() should also
> get 'run.dontcheck' argument in addition to its 'run.dontrun'
> and Rd2ex() a similar enhancement I'm looking into that.
>
> > Fixing that one causes the error to happen later.
>
> "fascinating", as Kurt may say ..
>
> >> OTOH, if '1)' is too much work for us, we could add this as a
> >> 'wishlist' item and wait for someone to send patches..
>
> > Alternatively, we could require the recommended packages for all tests.
>
> > Duncan Murdoch
>
> which seems too extreme. If some people really only want to test
> something like "the R base engine", they should be easily able
> to do so, and I still think that 'make check' should do exactly that.
> In the tests/Makefile.{common|in} this is even called
> "test-all-basics"
>
> One thing to consider might remove 'Examples' from the "all-basics"
> and use 'Examples' only in a new make target between "basics"
> and "devel".
> But personally, I'd strive for fixing the few (I hope) cases in
> the Examples we currently have.
> Using the \dontcheck{..} tag should really help there.
I don't think we should be removing tests for everybody to allow a few
people to test a build of R that none of us actually use.
The choice of name "recommended" is unfortunate, because it suggests
that these packages are not necessary in order to get R to run: but a
build that doesn't contain them won't work properly. The test is giving
correct results: R "without-recommended" is broken.
We might be able to get it to pass "make check" by removing tests, but
example(capture.output) and example(glm) will still fail.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 3.1.1 and 3.1.2 both fail their test suites
> Duncan Murdoch
> on Mon, 3 Nov 2014 06:28:19 -0500 writes:
> On 03/11/2014, 4:17 AM, Martin Maechler wrote:
>>> Duncan Murdoch
>>> on Sat, 1 Nov 2014 13:17:56 -0400 writes:
>>
>> > On 01/11/2014, 11:33 AM, Peter Simons wrote:
>> >> Hi Uwe,
>> >>
>> >> > Nobody in R core runs NixOS and can reproduce
>> >> this. This passes on most > other platforms,
>> >> apparently. If you can point us to a problem or send >
>> >> patches, we'd appreciate it.
>> >>
>> >> have tried running the test suite in a build that's
>> >> configured with '--without-recommended-packages'? That's
>> >> about the only unusual thing we do when building with
>> >> Nix. Other than that, our build runs on a perfectly
>> >> ordinary Linux -- and it used to succeed fine in earlier
>> >> versions of R.
>>
>> > The tests "make check-devel" and "make check-all" are
>> > documented to require the recommended packages, and will
>> > fail without them. On Windows, "make check" also needs
>> > them, so this may be true on other systems as well.
>>
>> Thank you Duncan, for clarifying (above and later in the thread).
>>
>> Would it be hard to strive for
>>
>> 1) 'make check' should pass without-rec
>> 2) 'make check-devel' etc do require the recommended packages.
>>
>> That would be ideal I think - and correspond to the fact that
>> we call the recommended packages 'recommended' only.
> I think we could avoid errors in make check, but not warnings. People
> need to understand what the tests are testing, and recognize that some
> warnings are ignorable.
> To do this, we'd need to make sure that no examples in base packages
> require the use of recommended packages. Currently the failure happens
> in capture.output, because it runs the glm example which needs MASS.
> (The glm example is marked not to need MASS during testing, but the
> capture.output example runs everything.)
aah.. that's interesting in itself: Maybe example() should also
get 'run.dontcheck' argument in addition to its 'run.dontrun'
and Rd2ex() a similar enhancement I'm looking into that.
> Fixing that one causes the error to happen later.
"fascinating", as Kurt may say ..
>> OTOH, if '1)' is too much work for us, we could add this as a
>> 'wishlist' item and wait for someone to send patches..
> Alternatively, we could require the recommended packages for all tests.
> Duncan Murdoch
which seems too extreme. If some people really only want to test
something like "the R base engine", they should be easily able
to do so, and I still think that 'make check' should do exactly that.
In the tests/Makefile.{common|in} this is even called
"test-all-basics"
One thing to consider might remove 'Examples' from the "all-basics"
and use 'Examples' only in a new make target between "basics"
and "devel".
But personally, I'd strive for fixing the few (I hope) cases in
the Examples we currently have.
Using the \dontcheck{..} tag should really help there.
Martin Maechler
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] Calculation of cross-correlation in ccf
The acf and ccf functions assume that time series are stationary, but yours are
not.
I think that your alternative function is not well founded. You take a separate
mean for each sub-series, which implicitly allows the mean of the series to
vary arbitrarily with time. However, you only have one instance of each time
series so you can't have a non-parametric model for the means.
A parametric approach is to remove a linear trend from the series and then
apply ccf:
e1 <- residuals(lm(y1 ~ x))
e2 <- residuals(lm(y1 ~ x))
ccf(e1, e2)
which does identify a lag of -8 as the best match, although the correlation is
somewhat lower than what you found (0.87).
Martyn
From: r-devel-boun...@r-project.org [r-devel-boun...@r-project.org] on behalf
of Sami Toppinen [sami.toppi...@kolumbus.fi]
Sent: 04 November 2014 09:44
To: r-devel@r-project.org
Subject: [Rd] [R] Calculation of cross-correlation in ccf
Dear All,
I am studying some process measurement time series in R and trying to identify
time delays using cross-correlation function ccf. The results have however been
bit confusing. I found a couple of years old message about this issue but
unfortunately wasn't able to find it again for a reference.
For example, an obvious time shift is observed between the measurements y1 and
y2 when the following test data is plotted:
x <- 1:121
y1 <- c(328.27, 328.27, 328.27, 328.27, 328.21, 328.14, 328.14, 328.01,
328.07, 328.01, 327.87, 328.01, 328.07, 328.27, 328.27, 328.54, 328.61,
328.74, 328.88, 329.01, 329.01, 329.21, 329.28, 329.35, 329.35, 329.42,
329.35, 329.28, 329.28, 329.15, 329.08, 329.08, 328.95, 328.95, 328.95,
328.95, 329.01, 329.15, 329.21, 329.28, 329.55, 329.62, 329.75, 329.82,
329.89, 330.09, 330.09, 330.29, 330.29, 330.36, 330.42, 330.29, 330.15,
330.22, 330.09, 329.95, 329.82, 329.75, 329.62, 329.55, 329.48, 329.55,
329.68, 329.75, 329.82, 329.89, 330.09, 330.09, 330.15, 330.22, 330.42,
330.42, 330.42, 330.36, 330.42, 330.22, 330.15, 330.09, 329.89, 329.75,
329.55, 329.35, 329.35, 329.42, 329.48, 329.55, 329.75, 329.75, 329.82,
330.09, 330.15, 330.42, 330.42, 330.62, 330.69, 330.69, 330.83, 330.83,
330.76, 330.62, 330.62, 330.56, 330.42, 330.42, 330.29, 330.29, 330.29,
330.29, 330.22, 330.49, 330.56, 330.62, 330.76, 331.03, 330.96, 331.16,
331.23, 331.50, 331.63, 332.03, 332.03)
y2 <- c(329.68, 329.75, 329.82, 329.95, 330.02, 330.15, 330.22, 330.36,
330.22, 330.29, 330.29, 330.29, 330.29, 330.15, 330.22, 330.22, 330.15,
330.15, 330.15, 330.15, 330.15, 330.29, 330.49, 330.49, 330.62, 330.89,
331.03, 331.09, 331.16, 331.30, 331.30, 331.36, 331.43, 331.43, 331.43,
331.36, 331.36, 331.36, 331.36, 331.23, 331.23, 331.16, 331.16, 331.23,
331.30, 331.23, 331.36, 331.56, 331.70, 331.83, 331.97, 331.97, 332.10,
332.30, 332.44, 332.44, 332.51, 332.51, 332.57, 332.57, 332.51, 332.37,
332.24, 332.24, 332.10, 331.97, 331.97, 331.90, 331.83, 331.97, 331.97,
331.97, 332.03, 332.24, 332.30, 332.30, 332.37, 332.57, 332.57, 332.57,
332.57, 332.57, 332.51, 332.37, 332.30, 332.17, 331.97, 331.83, 331.70,
331.70, 331.63, 331.63, 331.70, 331.83, 331.90, 332.10, 332.24, 332.30,
332.44, 332.57, 332.71, 332.84, 332.77, 332.91, 332.84, 332.84, 332.91,
332.84, 332.77, 332.77, 332.64, 332.64, 332.57, 332.57, 332.57, 332.57,
332.57, 332.71, 332.98, 333.24, 333.58)
matplot(cbind(y1, y2))
However, the cross-correlation function surprisingly gives the maximum
correlation 0.83 at zero lag:
ccf(y1, y2)
Plotting of variables against each other with zero lag
plot(y1, y2)
shows that the correlation is not that good. Instead, a very nice correlation
is obtained with a plot with shifted variables:
plot(y1[1:113], y2[1:113 + 8])
As a comparison I defined my own cross correlation function:
cross.cor <- function(x, y, k)
{
n <- length(x) - abs(k)
if (k >= 0)
cor(x[1:n + k], y[1:n])
else
cor(x[1:n], y[1:n - k])
}
The new function cross.cor gives maximum correlation of 0.99 at lag -8, and the
shape of the correlation function is very different from the one obtained with
ccf (both methods give same value at zero lag):
plot(-15:15, sapply(-15:15, function(lag) cross.cor(y1, y2, lag)),
ylim = c(0.3, 1))
points(-15:15, ccf(y1, y2, 15, plot = FALSE)$acf, col = "red")
In order to understand the reason for the differences, I looked at the program
codes of ccf function. When the variables are compared with a nonzero lag, some
the data points must be left out from the tails of the time series. It appears
to me that ccf calculates (partly in R code, partly in C code) first the means
and the standard deviations using the whole data, and then uses those values as
constants in further calculations. The time series are truncated only in the
summations for covariances.
That approach naturally speeds up the computations, but is it really correct?
Is the approach used in ccf somehow statistically more correct? I suppose th
