[Rcpp-devel] Bug with table sugar and NumericVector in Rcpp 0.10.3
Kevin Ushey
kevinushey at gmail.com
Fri Mar 29 18:09:10 CET 2013
Great. Thanks for the quick response and all the work you and Romain put
into Rcpp!
-Kevin
On Fri, Mar 29, 2013 at 9:35 AM, Dirk Eddelbuettel <edd at debian.org> wrote:
>
> On 29 March 2013 at 08:48, Kevin Ushey wrote:
> | Thanks for the quick responses.
>
> Thanks for the reproducible bug report.
>
> In (some version of) Rcpp 0.10.3.1 [1] you can now use your function again:
>
> R> sourceCpp("/tmp/kevin.cpp")
> R> set.seed(42)
> R> x <- sample(1:10, 20, replace=TRUE)
> R> table(x)
> x
> 2 3 5 6 7 8 9 10
> 2 2 3 2 2 3 1 5
> R> counts(x)
> 2 3 5 6 7 8 9 10
> 2 2 3 2 2 3 1 5
> R>
>
>
> | It seems counter-productive for R Core to be
> | removing API entry points, at least doing so without informing package
>
> Not quite as we were using a non-exported function. The counter-productive
> nature of this is solely on "their" decision of what is, and what is not,
> part of the API. If we use something we are not supposed to use, we get to
> pay the price of it being pulled.
>
> "They" are pretty good about maintaining what is the declared API.
>
> | maintainers of newly implemented and tested alternatives. I wonder if
> it's due
> | to the introduction of 'long' vectors, and the team decided it would be
> easier
> | to just remove the API entry points, rather than adapting them? Just
> | conjecture, though.
>
> No relationship.
>
> Dirk
>
> [1] In attempting to address the long-standding (and very annoying) but
> with
> Date.Frame, Romain inadvertently broke SVN trunk. And I am not managing to
> get it back right now. But if you apply my revision 4297 to, say, the
> 0.10.3
> release (and hence ignore the Data.Frame change) then the resulting
> 0.10.3.1
> build, tests, and gets your counts() function back.
>
> |
> | Thanks for the help.
> | -Kevin
> |
> | On Fri, Mar 29, 2013 at 8:20 AM, <romain at r-enthusiasts.com> wrote:
> |
> | Cool. I'll have a look when I'm back from easter weekend.
> |
> | Romain
> |
> | Le 2013-03-29 16:00, Dirk Eddelbuettel a écrit :
> |
> |
> | On 29 March 2013 at 09:40, Dirk Eddelbuettel wrote:
> | |
> | | On 29 March 2013 at 15:24, romain at r-enthusiasts.com wrote:
> | | | Le 2013-03-29 14:31, Dirk Eddelbuettel a écrit :
> | | | > On 29 March 2013 at 09:11, romain at r-enthusiasts.com wrote:
> | | | > |
> | | | > | Hello,
> | | | > |
> | | | > | This is related to this change:
> | | | > |
> | | | > | 2013-01-15 Dirk Eddelbuettel <edd at debian.org>
> | | | > |
> | | | > | * src/api.cpp (Rcpp): Commented-out
> | coerce_to_string() for real
> | | | > and
> | | | > | complex arguments as R-devel (as of today)
> dislikes
> | use of non-API
> | | | > | functions Rf_EncodeComplex’, ‘Rf_EncodeReal’,
> | ‘Rf_formatComplex’
> | | | > |
> | | | > | So maybe Dirk has a plan to fix it.
> | | | >
> | | | > I do not.
> | | |
> | | | Fine. So I'll fix it.
> | |
> | | Hold on.
> | |
> | | I am in the middle of it. I do have a poor replacementment for
> | EncodeReal,
> | | and am about to test one for complex. Will post soon.
> | |
> | | Am not covering scientific notation at this point.
> |
> | Ok, here replacement candidates. Kudos to Kevin for sending
> something
> | reproducible that triggered this. This snipped below grew from
> his
> | code and
> | provids replacement candidates for coerce_to_string() for the
> real and
> | complex cases, not using the internal R functions (which I also
> did not
> | look
> | at). Obviously the function headers need to change from the
> sample to
> | what
> | api.cpp uses.
> |
> | What we get is simple snprintf() calls which almost surely is
> less
> | featureful
> | than what R has, but please complaon to R Core about the
> sillyness of
> | us not
> | being able to use _existing and tested functions_. It's painful.
> |
> |
> | Dirk
> |
> | #include <Rcpp.h>
> |
> | static const char* dropTrailing0(char *s, char cdec) {
> | /* Note that 's' is modified */
> | char *p = s;
> | for (p = s; *p; p++) {
> | if(*p == cdec) {
> | char *replace = p++;
> | while ('0' <= *p && *p <= '9')
> | if(*(p++) != '0')
> | replace = p;
> | if(replace != p)
> | while((*(replace++) = *(p++)))
> | ;
> | break;
> | }
> | }
> | return s;
> | }
> |
> | //template <>
> | // const char* coerce_to_string/*<REALSXP>*/(double x){
> | // [[Rcpp::export]]
> | const char* coerce_to_stringRE(double x){
> | int w,d,e ;
> | // cf src/main/format.c in R's sources:
> | // The return values are
> | // w : the required field width
> | // d : use %w.df in fixed format, %#w.de in scientific
> | format
> | // e : use scientific format if != 0, value is number of
> | exp
> | digits - 1
> | //
> | // nsmall specifies the minimum number of decimal digits in
> | fixed format:
> | // it is 0 except when called from do_format.
> | Rf_formatReal( &x, 1, &w, &d, &e, 0 ) ;
> | // we are no longer allowed to use this:
> | // char* tmp = const_cast<char*>( Rf_EncodeReal(x, w, d,
> e,
> | '.') );
> | // so approximate it poorly as
> | char tmp[128];
> | snprintf(tmp, 127, "%*.*f", w, d, x);
> | //Rcpp::Rcout << "Vec is " << vec << std::endl;
> | return dropTrailing0(tmp, '.');
> |
> | }
> |
> | //template <>
> | //const char* coerce_to_string/*<CPLXSXP>*/(Rcomplex x){
> | // [[Rcpp::export]]
> | std::string coerce_to_stringCP(Rcomplex x){
> | int wr, dr, er, wi, di, ei;
> | // cf src/main/format.c in R's sources:
> | Rf_formatComplex(&x, 1, &wr, &dr, &er, &wi, &di, &ei, 0);
> | //return Rf_EncodeComplex(x, wr, dr, er, wi, di, ei, '.' );
> |
> | // we are no longer allowed to use this:
> | // Rf_EncodeComplex(x, wr, dr, er, wi, di, ei, '.' );
> | // so approximate it poorly as
> | char tmp[128];
> | snprintf(tmp, 127, "%*.*f+%*.*fi", wr, dr, x.r, wi, di, x.i);
> | return std::string(tmp); // force a copy
> | }
> |
> | using namespace Rcpp;
> |
> | // // [[Rcpp::export]]
> | // IntegerVector counts(NumericVector x) {
> | // return table(x);
> | // }
> |
> |
> | _______________________________________________
> | Rcpp-devel mailing list
> | Rcpp-devel at lists.r-forge.r-project.org
> |
> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
> |
> |
>
> --
> Dirk Eddelbuettel | edd at debian.org | http://dirk.eddelbuettel.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20130329/e74dfc7b/attachment-0001.html>
More information about the Rcpp-devel
mailing list