Bug report: cbind with numeric and raw gives incorrect result

For what it's worth the following patch fixes that particular problem on my system.? I have not checked very carefully to make sure this does not cause other problems, but at a high level it seems to make sense.? In this particular part of the code I believe `mode` is taken to be the highest type of "column" encountered by `ctype` and based on conditionals it can (I think) be up to REALSXP here.? This leads to a `INTEGER(REALSXP)` call, which presumably messes up the underlying double bit representation.

Again, I looked at this very quickly so I could be completely wrong, but I did at least build R with this patch and then no longer observed the odd behavior reported by mikefc.

Index: src/main/bind.c
===================================================================
--- src/main/bind.c?? ?(revision 75340)
+++ src/main/bind.c?? ?(working copy)
@@ -1381,11 +1381,16 @@
??? ??? ??? ?MOD_ITERATE1(idx, k, i, i1, {
??? ??? ??? ???? LOGICAL(result)[n++] = RAW(u)[i1] ? TRUE : FALSE;
??? ??? ??? ?});
-?? ??? ???? } else {
+?? ??? ???? } else if (mode == INTSXP) {
??? ??? ??? ?R_xlen_t i, i1;
??? ??? ??? ?MOD_ITERATE1(idx, k, i, i1, {
??? ??? ??? ???? INTEGER(result)[n++] = (unsigned char) RAW(u)[i1];
??? ??? ??? ?});
+?? ??? ???? } else {
+?? ??? ??? ?R_xlen_t i, i1;
+?? ??? ??? ?MOD_ITERATE1(idx, k, i, i1, {
+?? ??? ??? ???? REAL(result)[n++] = (unsigned char) RAW(u)[i1];
+?? ??? ??? ?});
??? ??? ???? }
??? ??? ?}
??? ???? }

Hi there,

using cbind with a numeric and raw argument produces an incorrect result.

I've posted some details below,

kind regards,
Mike.



e.g.

cbind(0, as.raw(0))

? ? [,1]? ? ? ? ? [,2]
[1,]? ? 0 6.950136e-310



A longer example shows that the result is not a rounding error, is not
consistent, and repeated applications get different results.

cbind(0, as.raw(1:10))

? ? ? ? ? ? ? [,1]? ? ? ? ? [,2]
[1,]? 0.000000e+00? 0.000000e+00
[2,]? 0.000000e+00? 0.000000e+00
[3,]? 0.000000e+00? 0.000000e+00
[4,]? 0.000000e+00? 0.000000e+00
[5,]? 0.000000e+00? 6.950135e-310
[6,] 4.243992e-314? 6.950135e-310
[7,] 8.487983e-314? 6.324040e-322
[8,] 1.273197e-313? 0.000000e+00
[9,] 1.697597e-313 -4.343725e-311
[10,] 2.121996e-313? 1.812216e-308


This bug occurs on
* mac os (with R 3.5.1)
* linux (with R 3.4.4)
* Windows (with R 3.5.0)




My Session Info
R version 3.5.1 (2018-07-02)
Platform: x86_64-apple-darwin15.6.0 (64-bit)
Running under: macOS High Sierra 10.13.6

Matrix products: default
BLAS: /System/Library/Frameworks/Accelerate.framework/Versions/
A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
LAPACK: /Library/Frameworks/R.framework/Versions/3.5/
Resources/lib/libRlapack.dylib

locale:
[1] en_AU.UTF-8/en_AU.UTF-8/en_AU.UTF-8/C/en_AU.UTF-8/en_AU.UTF-8

attached base packages:
[1] stats? ? graphics? grDevices utils? ? datasets? methods? base

other attached packages:
[1] memoise_1.1.0? ggplot2_3.0.0? nonogramp_0.1.0 purrr_0.2.5
dplyr_0.7.6

loaded via a namespace (and not attached):
[1] Rcpp_0.12.18? ? rstudioapi_0.7? bindr_0.1.1? ? ? magrittr_1.5
tidyselect_0.2.4 munsell_0.5.0? ? colorspace_1.3-2 R6_2.2.2
rlang_0.2.1.9000 stringr_1.3.1? ? plyr_1.8.4? ? ? tools_3.5.1
grid_3.5.1
[14] packrat_0.4.9-3? gtable_0.2.0? ? withr_2.1.2? ? ? digest_0.6.15
lazyeval_0.2.1? assertthat_0.2.0 tibble_1.4.2? ? crayon_1.3.4
bindrcpp_0.2.2? pryr_0.1.4? ? ? codetools_0.2-15 glue_1.3.0
labeling_0.3
[27] stringi_1.2.4? ? compiler_3.5.1? pillar_1.3.0? ? scales_0.5.0
pkgconfig_2.0.1

??? [[alternative HTML version deleted]]

______________________________________________
R-devel at r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel