[Rd] Fwd: Bug report: cbind with numeric and raw gives incorrect result
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.00e+00 0.00e+00 [2,] 0.00e+00 0.00e+00 [3,] 0.00e+00 0.00e+00 [4,] 0.00e+00 0.00e+00 [5,] 0.00e+00 6.950135e-310 [6,] 4.243992e-314 6.950135e-310 [7,] 8.487983e-314 6.324040e-322 [8,] 1.273197e-313 0.00e+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.0colorspace_1.3-2 R6_2.2.2 rlang_0.2.1.9000 stringr_1.3.1plyr_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.4compiler_3.5.1 pillar_1.3.0 scales_0.5.0 pkgconfig_2.0.1 [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] 2 minor typos
Hello,
I would like to report 2 very minor typos:
1. help file for package:base function:function
The last sentence of the "Technical details" section reads:
"This is not normally user-visible, but it indicated when functions are
printed."
Either "is" is missing ("but it is indicated") or "it" should be replaced by
"is" ("but is indicated") if the subject is omitted.
2. R FAQ, mailing list section
(https://cran.r-project.org/doc/FAQ/R-FAQ.html#What-mailing-lists-exist-for-R_003f)
For the R-package-devel list, the section reads:
"A list which which provides a forum for learning about the R package
development process."
(Double "which").
If this was not the proper list or the proper way to report such minor typos,
please do let me know so that I will know better in the future.
Thank you!
Best,
-
Marie-Helene Burle (Marie)
PhD candidate (Centre for Wildlife Ecology)
R Data Peer (Research Commons)
Writing Facilitator (Student Learning Commons)
Data and Software Carpentry instructor
RStudio Community sustainer
Scientific Programming Study Group admin
-
Simon Fraser University
(+1) 778 782-5618
http://www.sfu.ca/content/sfu/biology/people/profiles/msb2.html
https://github.com/prosoitos
https://twitter.com/MHBurle
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Possible bug, max argument in print.default(), on R-3.5.1-patched
> peter dalgaard
> on Mon, 24 Sep 2018 10:16:07 +0200 writes:
> Not in print.default(), but in print.data.frame(), which
> is now doing its own max= handling but not passing max to
> print.default (maechler, r75122 --- was this really for
> r-patched? -pd
Yes, because it solved an embarrasing thinko which lead to
enormous time spent for printing a few lines in extreme cases.
This was an incomplete bug-fix backport.. which I now have
completed (R-patched, svn rev >= 75359).
I'm sorry for the hassle.
Thank you, Gábor, for the report, and Peter for the digging!
Martin
>> On 22 Sep 2018, at 23:46 , Gábor Csárdi
>> wrote:
>>
>> The max argument of print.default() does not override
>> options(max.print), see below. R 3.5.1 and R-devel both
>> seem good.
>>
>> Gábor
>>
>>> options(max.print = 1) print(data.frame(a=1:10))
>> a 1 1 [ reached 'max' / getOption("max.print") -- omitted
>> 9 rows ]
>>> print(data.frame(a=1:10), max = 100)
>> a 1 1 [ reached getOption("max.print") -- omitted 9 rows
>> ]
>>> options(max.print = 1000) R.version
>> _ platform x86_64-w64-mingw32 arch x86_64 os mingw32
>> system x86_64, mingw32 status Patched major 3 minor 5.1
>> year 2018 month 09 day 11 svn rev 75286 language R
>> version.string R version 3.5.1 Patched (2018-09-11
>> r75286) nickname Feather Spray
>>>
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
> --
> Peter Dalgaard, Professor, Center for Statistics,
> Copenhagen Business School Solbjerg Plads 3, 2000
> Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23
> Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Fwd: 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];
+ });
}
}
}
On Tuesday, September 25, 2018, 7:58:31 AM EDT, mikefc
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.00e+00 0.00e+00
[2,] 0.00e+00 0.00e+00
[3,] 0.00e+00 0.00e+00
[4,] 0.00e+00 0.00e+00
[5,] 0.00e+00 6.950135e-310
[6,] 4.243992e-314 6.950135e-310
[7,] 8.487983e-314 6.324040e-322
[8,] 1.273197e-313 0.00e+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@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Fwd: Bug report: cbind with numeric and raw gives incorrect result
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,
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 <
> mik...@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.00e+00 0.00e+00
> [2,] 0.00e+00 0.00e+00
> [3,] 0.00e+00 0.00e+00
> [4,] 0.00e+00 0.00e+00
> [5,] 0.00e+00 6.950135e-310
> [6,] 4.243992e-314 6.950135e-310
> [7,] 8.487983e-314 6.324040e-322
> [8,] 1.273197e-313 0.00e+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] statsgraphics grDevices utilsdatasets 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.18rstudioapi_0.7 bindr_0.1.1 magrittr_1.5
> tidyselect_0.2.4 munsell_0.5.0colorspace_1.3-2 R6_2.2.2
> rlang_0.2.1.9000 stringr_1.3.1plyr_1.8.4 tools_3.5.1
> grid_3.5.1
> [14] packrat_0.4.9-3 gtable_0.2.0withr_2.1.2 digest_0.6.15
> lazyeval_0.2.1 assertthat_0.2.0 tibble_1.4.2crayon_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.4compiler_3.5.1 pillar_1.3.0scales_0.5.0
> pkgconfig_2.0.1
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Fwd: Bug report: cbind with numeric and raw gives incorrect result
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,
| 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 <
| > mik...@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.00e+00 0.00e+00
| > [2,] 0.00e+00 0.00e+00
| > [3,] 0.00e+00 0.00e+00
| > [4,] 0.00e+00 0.00e+00
| > [5,] 0.00e+00 6.950135e-310
| > [6,] 4.243992e-314 6.950135e-310
| > [7,] 8.487983e-314 6.324040e-322
| > [8,] 1.273197e-313 0.00e+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] statsgraphics grDevices utilsdatasets 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.18rstudioapi_0.7 bindr_0.1.1 magrittr_1.5
| > tidyselect_0.2.4 munsell_0.5.0colorspace_1.3-2 R6_2.2.2
| > rlang_0.2.1.9000 stringr_1.3.1plyr_1.8.4 tools_3.5.1
| > grid_3.5.1
| > [14] packrat_0.4.9-3 gtable_0.2.0withr_2.1.2 digest_0.6.15
| > lazyeval_0.2.1 assertthat_0.2.0 tibble_1.4.2crayon_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.4compiler_3.5.1 pillar_1.3.0scales_0.5.0
| > pkgconfig_2.0.1
| >
| > [[alternative HTML version deleted]]
| >
| > __
| > R-devel@r-project.org mailing list
| > https://stat.ethz.ch/mailman/listinfo/r-devel
| >
|
| [[alternative HTML version deleted]]
|
| __
| R-devel@r-project.org mailing
Re: [Rd] Fwd: Bug report: cbind with numeric and raw gives incorrect result
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
> 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.00e+00 0.00e+00
> [2,] 0.00e+00 0.00e+00
> [3,] 0.00e+00 0.00e+00
> [4,] 0.00e+00 0.00e+00
> [5,] 0.00e+00 6.950135e-310
> [6,] 4.243992e-314 6.950135e-310
> [7,] 8.487983e-314 6.324040e-322
> [8,] 1.273197e-313 0.00e+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@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
> __
> R-devel@r-project.org 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 andFax: 319-335-3017
Actuarial Science
241 Schaeffer Hall email: luke-tier...@uiowa.edu
Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] as.vector() broken on a matrix or array of type "list"
Hi, Unlike on an atomic matrix, as.vector() doesn't drop the "dim" attribute of matrix or array of type "list": m <- matrix(list(), nrow=2, ncol=3) m # [,1] [,2] [,3] # [1,] NULL NULL NULL # [2,] NULL NULL NULL as.vector(m) # [,1] [,2] [,3] # [1,] NULL NULL NULL # [2,] NULL NULL NULL is.vector(as.vector(m)) # [1] FALSE Thanks, H. -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fredhutch.org Phone: (206) 667-5791 Fax:(206) 667-1319 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
