[Rcpp-devel] strange bool conversion?

[Dirk Eddelbuettel]

On 10 January 2011 at 13:36, Daniel Sabanés Bové wrote:
| Hi Dirk,
| 
| thanks for your quick response.
| 
| I think this is a bug if you as a programmer think "OK, Rcpp does nice
| implicit conversion for me" and indeed it does not do the right thing.

I think the problem is, as they say, between your keyboard and chair.  If
'assumptions' always panned out, we wouldn't need to test.  Why do you think
all these <insert fashionable software engineering term of the decade>
methodologies insist on testing?

Trust is good. Testing is better.
 
| Also note that this behaviour was only introduced in the previous
| version of Rcpp, before my code worked without the explicit statement.
| So previously working code was broken.

You win some, you loose some. We now have much more sugar and other templated
goodies.  If the older version works better for you, by all means use the
older version.
 
| If you really decide to leave it as it is, I think you should at least
| explicitly warn the user in the manuals.

Please contribute a patch to whichever part of the documentation you seem lacking.
 
Regards,  Dirk

| Kind regards,
| Daniel
| 
| -------- Original Message --------
| Subject: Re: [Rcpp-devel] strange bool conversion?
| From: Dirk Eddelbuettel <edd at debian.org>
| To: Daniel Sabanés Bové <daniel.sabanesbove at ifspm.uzh.ch>
| Date: Mon 10 Jan 2011 13:26:05 CET
| 
| > 
| > On 10 January 2011 at 12:06, Daniel Sabanés Bové wrote:
| > | Hi,
| > | 
| > | I have to report another serious bug in argument extraction, now with
| > | integers.
| > | (It seems to me that the fix by Romain could have been causing this
| > | behaviour?)
| > | Moreover, the problem does not depend on a "const" modifier:
| > | 
| > | -- snip --
| > | 
| > | library(Rcpp)
| > | library(inline)
| > | 
| > | ## this compiles and loads fine, but is wrong:
| > | wrong <- cxxfunction(signature(x="list") , '
| > |          List input(x);
| > |          int a = input[0];
| > |          return wrap(a);
| > |          ' , plugin = "Rcpp")
| > | 
| > | ## still OK:
| > | wrong(list(1))
| > | 
| > | ## all 1:
| > | wrong(list(4))
| > | wrong(list(4L))
| > | wrong(list(-4L))
| > | 
| > | 
| > | ## this is correct:
| > | correct <- cxxfunction(signature(x="list") , '
| > |          List input(x);
| > |          int a = as<int>(input[0]);
| > |          return wrap(a);
| > |          ' , plugin = "Rcpp")
| > | 
| > | correct(list(1))
| > | wrong(list(4))
| > | wrong(list(4L))
| > | wrong(list(-4L))
| > | 
| > | -- snap --
| > 
| > So where is the bug?  
| > 
| > R> correct(list(a=42))
| > [1] 42
| > R> correct(list(a=42L))
| > [1] 42
| > R> correct(list(a=-42L))
| > [1] -42
| > R>  
| > 
| > There is nothing wrong with helping the compiler via explicit template use as
| > in 
| > 
| > 	int a = as<int>(input[0]);
| > 
| > Dirk
| > 
| >  
| > | The sessionInfo():
| > | 
| > | 
| > | R version 2.12.1 (2010-12-16)
| > | Platform: i686-pc-linux-gnu (32-bit)
| > | 
| > | locale:
| > |  [1] LC_CTYPE=de_CH.utf8       LC_NUMERIC=C            
| > |  [3] LC_TIME=de_CH.utf8        LC_COLLATE=de_CH.utf8   
| > |  [5] LC_MONETARY=C             LC_MESSAGES=de_CH.utf8  
| > |  [7] LC_PAPER=de_CH.utf8       LC_NAME=C               
| > |  [9] LC_ADDRESS=C              LC_TELEPHONE=C          
| > | [11] LC_MEASUREMENT=de_CH.utf8 LC_IDENTIFICATION=C     
| > | 
| > | attached base packages:
| > | [1] stats     graphics  grDevices utils     datasets  methods   base    
| > | 
| > | other attached packages:
| > | [1] inline_0.3.8 Rcpp_0.9.0 
| > | 
| > | loaded via a namespace (and not attached):
| > | [1] tools_2.12.1
| > | 
| > | 
| > | Kind regards,
| > | Daniel
| > | 
| > | > This is fixed now (rev 2789). For the curious, it seems that the
| > | > generic_proxy template made the wrong choice between these conversion
| > | > operators: operator SEXP() const { return get() ; } template <typename
| > | > U> operator U() const { return ::Rcpp::as<U>(get()) ; } I resolved
| > | > this by forcing the conversion to bool with this: operator bool()
| > | > const { return ::Rcpp::as<bool>(get()) ; } Thanks again for the
| > | > report. Romain Le 13/12/10 17:30, Daniel Saban?s Bov? a ?crit :
| > | >> > Hi,
| > | >> >
| > | >> > I have just discovered an extremely strange behaviour in conversion of
| > | >> > an R logical to a C++ bool. Consider the minimal example:
| > | >> >
| > | >> > --- snip ---
| > | >> >
| > | >> > library(Rcpp)
| > | >> > library(inline)
| > | >> >
| > | >> > ## this compiles and loads fine, but is wrong:
| > | >> > wrong<- cxxfunction(signature(x="list") , '
| > | >> >          List input(x);
| > | >> >          const bool a = input[0];
| > | >> >          return wrap(a);
| > | >> >          ' , plugin = "Rcpp")
| > | >> >
| > | >> > wrong(list(TRUE))
| > | >> > wrong(list(FALSE))
| > | >> >
| > | >> > ## this is correct:
| > | >> > correct<- cxxfunction(signature(x="list") , '
| > | >> >          List input(x);
| > | >> >          const bool a = as<bool>(input[0]);
| > | >> >          return wrap(a);
| > | >> >          ' , plugin = "Rcpp")
| > | >> >
| > | >> > correct(list(TRUE))
| > | >> > correct(list(FALSE))
| > | >> >
| > | >> > --- snap ----
| > | >> >
| > | >> > In Rcpp 0.8.9 wrong(list(FALSE)) == TRUE, which is quite surprising to
| > | >> > the user...
| > | >> > Sorry if this already a known feature, but then I would be curious if
| > | >> > this behaviour is really wished?
| > | >> >
| > | >> > Thanks in advance,
| > | >> > best regards
| > | >> >
| > | >> > Daniel
| > | > -- Romain Francois Professional R Enthusiast +33(0) 6 28 91 30 30
| > | > http://romainfrancois.blog.free.fr |- http://bit.ly/fT2rZM : highlight
| > | > 0.2-5 |- http://bit.ly/gpCSpH : Evolution of Rcpp code size `-
| > | > http://bit.ly/hovakS : RcppGSL initial release 
| > | 
| > | _______________________________________________
| > | 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