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

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

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

mikefc
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]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Bug report: cbind with numeric and raw gives incorrect result

R devel mailing list


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 <[hidden email]> 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]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Bug report: cbind with numeric and raw gives incorrect result

mikefc
Thanks Brodie, that's some nice detective work.

If someone wanted to grant me access to Bugzilla, I'll be happy to post the
bug and patch there (with your permission Brodie?) and help this bug get
fixed.

Mike.

On Tue., 25 Sep. 2018, 10:53 pm brodie gaslam, <[hidden email]>
wrote:

>
>
> 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 <
> [hidden email]> 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]]
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Bug report: cbind with numeric and raw gives incorrect result

Dirk Eddelbuettel

On 25 September 2018 at 22:59, mikefc wrote:
| Thanks Brodie, that's some nice detective work.
|
| If someone wanted to grant me access to Bugzilla, I'll be happy to post the
| bug and patch there (with your permission Brodie?) and help this bug get
| fixed.

I think it would help your cause if you were identifiable.

You know who you are dealing with. We do not. All we get is a first name, and
a "cool but useless" (so true, for once) handle on social media and email.

I don't set the rules for the bugzilla account, but if were me, I'd ask you
to give your name.

Sincerely,

Dirk

| Mike.
|
| On Tue., 25 Sep. 2018, 10:53 pm brodie gaslam, <[hidden email]>
| wrote:
|
| >
| >
| > 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 <
| > [hidden email]> 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]]
| >
| > ______________________________________________
| > [hidden email] mailing list
| > https://stat.ethz.ch/mailman/listinfo/r-devel
| >
|
| [[alternative HTML version deleted]]
|
| ______________________________________________
| [hidden email] mailing list
| https://stat.ethz.ch/mailman/listinfo/r-devel

--
http://dirk.eddelbuettel.com | @eddelbuettel | [hidden email]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Bug report: cbind with numeric and raw gives incorrect result

Tierney, Luke
In reply to this post by R devel mailing list
Thanks for the report and patch. Fixed in R-devel and R_patched.

Best,

luke

On Tue, 25 Sep 2018, brodie gaslam via R-devel wrote:

>
>
> 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 <[hidden email]> 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]]
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

--
Luke Tierney
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa                  Phone:             319-335-3386
Department of Statistics and        Fax:               319-335-3017
    Actuarial Science
241 Schaeffer Hall                  email:   [hidden email]
Iowa City, IA 52242                 WWW:  http://www.stat.uiowa.edu
______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel