[Rd] Fwd: Bug report: cbind with numeric and raw gives incorrect result

[brodie gaslam]

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];
+            });
             }
         }
         }






On Tuesday, September 25, 2018, 7:58:31 AM EDT, mikefc <mikefc using coolbutuseless.com> wrote: 





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 using r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel