Re: [R] ReadItem: Error

[Jeff Reichman]

> infoRDS("climate_raster.rds")
$version
[1] 2

$writer_version
[1] "3.5.0"

$min_reader_version
[1] "2.3.0"

$format
[1] "xdr"

-Original Message-
From: Bert Gunter  
Sent: Saturday, September 18, 2021 11:40 AM
To: reichm...@sbcglobal.net
Cc: R-help 
Subject: Re: [R] ReadItem: Error

Did you try infoRDS() ?  It **may** tell you something useful, though it cannot 
tell you whether the file is corrupted or not. If you post its results here, 
someone **may** be able to tell you something informative.

That's all I got.

Bert Gunter

"The trouble with having an open mind is that people keep coming along and 
sticking things into it."
-- Opus (aka Berkeley Breathed in his "Bloom County" comic strip )

On Sat, Sep 18, 2021 at 9:00 AM Jeff Reichman  wrote:
>
> Anyone see what I might be doing wrong? Corrupted rds file maybe. The 
> error would suggest I'm using an older version of R except I'm running 
> both the latest RStudio and R versions.
>
> # Load in the tidyverse, raster, and sf packages
> library(tidyverse)
> library(raster)
> library(sf)
>
> # Read the climate data from an rds file climate <- 
> readRDS("Datasets/climate_raster.rds")
>
> # Have a look at the variables in the climate data
> colnames(climate)
>
> # Convert to SpatialPixelDataFrame for plotting climate_df <- mutate(
>   .data = climate,
>   rasters = map(
> .x = rasters,
> ~ as_tibble(as(.x, "SpatialPixelsDataFrame" %>%
>   unnest(cols = c(rasters))
>
> > climate <- readRDS("Datasets/climate_raster.rds")
> Error in readRDS("Datasets/climate_raster.rds") :
>   ReadItem: unknown type 0, perhaps written by later version of R
>
> __
> R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see 
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide 
> http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] Improvement: function cut

[David Winsemius]

On 9/18/21 5:28 AM, Leonard Mada via R-help wrote:

Hello Andrew,


I add this info as a completion (so other users can get a better
understanding):

If we want to perform a survival analysis, than the interval should be
closed to the right, but we should include also the first time point (as
per Intention-to-Treat):

[0, 4](4, 8](8, 12](12, 16]

[0, 4](4, 8](8, 12](12, 16](16, 20]


So the series is extendible to the right without any errors!

But the 1st interval (which is the same in both series) is different
from the other intervals: [0, 4].


I feel that this should have been the default behaviour for cut().


To Leonard;

If you do not like the behavior of `cut`, then you should "roll your 
own". It's very unlikely that R Core will modify a base cunction like 
cut. You might want to look at Hmisc::cut2. Frank Harrell didn't like 
that default behavior and thought he could make a better cut, so he just 
put it in his package. I did like his version better and often used it 
when I was actively programming. I suspect there is also a tidyverse 
cut-like function, but I'm not terribly familiar with that fork of R. 
(It's really not the same language IMHO.)


But it's a waste of time and energy to try propose modifications of core 
R functions unless *you* can show that it is stable across 20,000 
packages and will not offend long-time users. The likelihood  of that 
happening for your proposal is vanishing small in my estimation. You 
shouldn't ask R Core to do that for you. They are busy fixing real bugs.



If you want to persist despite my negativity, then you should make a 
complete proposal by submitting a proper diff file that incorporates 
your tested efforts to the Rdevel mailing list.



--

David



Note:

I was induced to think about a different situation in my previous
message, as you constructed open intervals on the right, and also
extended to the right. But survival analysis should be as described in
this mail and should probably be the default.


Sincerely,


Leonard


On 9/18/2021 1:29 AM, Andrew Simmons wrote:

I disagree, I don't really think it's too long or ugly, but if you
think it is, you could abbreviate it as 'i'.


x <- 0:20
breaks1 <- seq.int (0, 16, 4)
breaks2 <- seq.int (0, 20, 4)
data.frame(
     cut(x, breaks1, right = FALSE, i = TRUE),
     cut(x, breaks2, right = FALSE, i = TRUE),
     check.names = FALSE
)


I hope this helps.

On Fri, Sep 17, 2021 at 6:26 PM Leonard Mada mailto:leo.m...@syonic.eu>> wrote:

 Hello Andrew,


 But "cut" generates factors. In most cases with real data one
 expects to have also the ends of the interval: the argument
 "include.lowest" is both ugly and too long.

 [The test-code on the ftable thread contains this error! I have
 run through this error a couple of times.]


 The only real situation that I can imagine to be problematic:

 - if the interval goes to +Inf (or -Inf): I do not know if there
 would be any effects when including +Inf (or -Inf).


 Leonard


 On 9/18/2021 1:14 AM, Andrew Simmons wrote:

 While it is not explicitly mentioned anywhere in the
 documentation for .bincode, I suspect 'include.lowest = FALSE' is
 the default to keep the definitions of the bins consistent. For
 example:


 x <- 0:20
 breaks1 <- seq.int (0, 16, 4)
 breaks2 <- seq.int (0, 20, 4)
 cbind(
     .bincode(x, breaks1, right = FALSE, include.lowest = TRUE),
     .bincode(x, breaks2, right = FALSE, include.lowest = TRUE)
 )


 by having 'include.lowest = TRUE' with different ends, you can
 get inconsistent behaviour. While this probably wouldn't be an
 issue with 'real' data, this would seem like something you'd want
 to avoid by default. The definitions of the bins are


 [0, 4)
 [4, 8)
 [8, 12)
 [12, 16]


 and


 [0, 4)
 [4, 8)
 [8, 12)
 [12, 16)
 [16, 20]


 so you can see where the inconsistent behaviour comes from. You
 might be able to get R-core to add argument 'warn', but probably
 not to change the default of 'include.lowest'. I hope this helps


 On Fri, Sep 17, 2021 at 6:01 PM Leonard Mada mailto:leo.m...@syonic.eu>> wrote:

 Thank you Andrew.


 Is there any reason not to make: include.lowest = TRUE the
 default?


 Regarding the NA:

 The user still has to suspect that some values were not
 included and run that test.


 Leonard


 On 9/18/2021 12:53 AM, Andrew Simmons wrote:

 Regarding your first point, argument 'include.lowest'
 already handles this specific case, see ?.bincode

 Your second point, maybe it could be helpful, but since both
 'cut.default' and '.bincode' return NA if a value isn't
 within a bin, you could make something like this on your own.
 Might be worth pitching to R-bugs on the 

Re: [R] Cacheing of functions from libraries other than the base in Rmarkdown

[Bert Gunter]

I think you should post on the RStudio help forums. They have specific
areas to ask for help on their stuff, at least for some of it. You may wish
to wait a bit before doing so, though, just to see if someone here responds.

Bert


On Sat, Sep 18, 2021, 12:26 PM Chris Evans  wrote:

> This question may belong somewhere else, if so, please signpost me and
> accept apologies.
>
> What is happening is that I have a large (for me, > 3k lines) Rmarkdown
> file with many R code blocks (no other code or
> engine is used) working on some large datasets.  I have some inline r like
>
>There are `r n_distinct(tibDat$ID)` participants and `r nrow(tibDat)`
> rows of data.
>
> What I am finding is that even if one knit has worked fine and I change
> something somewhere and knit again, the second
> knit is often failing with an error like
>
>n_distinct(tibDat$ID) : could not find function "n_distinct"
>
> This is not happening for functions like nrow() from base R and it mostly
> seems to happen to functions from the tidyverse.
>
> I think what is happening is some sort of cache corruption presumably
> caused by the memory demands.  I am pretty sure I've
> seen this before but a long time ago and dealt with it by deleting the
> files and cache folders created by the knit.  That
> works now too but as knitting the whole file now takes over 20 minutes, I
> really don't want to have to do that.
>
> I have found that replacing things with base functions fixes the problem
> every time, e.g. replacing `r n_distinct(tibDat$ID)`
> with `r length(unique(tibDat$ID))` works fine.  The other workaround is to
> compute what you need for the inline
> computation at the end of the preceding code block, trivial e.g. at the
> end of the preceding code block:
>
> n_distinct(tibDat$ID) -> tmpN
> ```
>
> and then
>
>   `r tmpN`
>
> that works fine so I have my workarounds but I guess I have three
> questions:
>
> 1) do others see this?
> 2) is there some setting that might, assuming my guess about the cause is
> correct, increase some storage somewhere and avert this?
> 3) if it is a bug, where should I report it (as I'm not sure what is
> causing it!)?
>
> Thanks in advance,
>
> Chris
>
>
>
> > sessionInfo()
> R version 4.1.1 (2021-08-10)
> Platform: x86_64-pc-linux-gnu (64-bit)
> Running under: Ubuntu 20.04.3 LTS
>
> Matrix products: default
> BLAS:   /usr/lib/x86_64-linux-gnu/openblas-pthread/libblas.so.3
> LAPACK: /usr/lib/x86_64-linux-gnu/openblas-pthread/liblapack.so.3
>
> locale:
>  [1] LC_CTYPE=en_GB.UTF-8   LC_NUMERIC=C
>  LC_TIME=en_GB.UTF-8LC_COLLATE=en_GB.UTF-8
>  LC_MONETARY=en_GB.UTF-8LC_MESSAGES=en_GB.UTF-8
> LC_PAPER=en_GB.UTF-8   LC_NAME=C
>  [9] LC_ADDRESS=C   LC_TELEPHONE=C
>  LC_MEASUREMENT=en_GB.UTF-8 LC_IDENTIFICATION=C
>
> attached base packages:
> [1] stats graphics  grDevices utils datasets  methods   base
>
> other attached packages:
>  [1] boot_1.3-28 CECPfuns_0.0.0.9041 janitor_2.1.0
>  lubridate_1.7.10forcats_0.5.1   stringr_1.4.0   dplyr_1.0.7
>  purrr_0.3.4 readr_2.0.1 tidyr_1.1.3
>  tibble_3.1.4
> [12] ggplot2_3.3.5   tidyverse_1.3.1 english_1.2-6
>  pander_0.6.4
>
> loaded via a namespace (and not attached):
>  [1] fs_1.5.0bit64_4.0.5 RColorBrewer_1.1-2
> httr_1.4.2  tools_4.1.1 backports_1.2.1 utf8_1.2.2
> R6_2.5.1rpart_4.1-15Hmisc_4.5-0 DBI_1.1.1
>
> [12] colorspace_2.0-2nnet_7.3-16 withr_2.4.2
>  tidyselect_1.1.1gridExtra_2.3   bit_4.0.4
>  compiler_4.1.1  cli_3.0.1   rvest_1.0.1
>  htmlTable_2.2.1 xml2_1.3.2
> [23] labeling_0.4.2  scales_1.1.1checkmate_2.0.0
>  corrr_0.4.3 odbc_1.3.2  digest_0.6.27   readODS_1.7.0
>  foreign_0.8-81  rmarkdown_2.11  base64enc_0.1-3
>  jpeg_0.1-9
> [34] pkgconfig_2.0.3 htmltools_0.5.2 dbplyr_2.1.1
> fastmap_1.1.0   RJDBC_0.2-8 htmlwidgets_1.5.4   rlang_0.4.11
> readxl_1.3.1rstudioapi_0.13 farver_2.1.0
> generics_0.1.0
> [45] jsonlite_1.7.2  magrittr_2.0.1  Formula_1.2-4
>  Matrix_1.3-4Rcpp_1.0.7  munsell_0.5.0   fansi_0.5.0
>  lifecycle_1.0.0 stringi_1.7.4   yaml_2.2.1
> snakecase_0.11.0
> [56] grid_4.1.1  blob_1.2.2  crayon_1.4.1
> lattice_0.20-44 haven_2.4.3 splines_4.1.1   hms_1.1.0
>  knitr_1.34  pillar_1.6.2reprex_2.0.1
> glue_1.4.2
> [67] evaluate_0.14   latticeExtra_0.6-29 data.table_1.14.0
>  modelr_0.1.8png_0.1-7   vctrs_0.3.8 tzdb_0.1.2
>   psy_1.1 cellranger_1.1.0gtable_0.3.0
> assertthat_0.2.1
> [78] xfun_0.26   broom_0.7.9 rsconnect_0.8.24
> viridisLite_0.4.0   survival_3.2-13 rJava_1.0-4 cluster_2.1.2
>  ellipsis_0.3.2
>
>
> --
> Chris Evans (he/him)  Visiting Professor, University of
> Sheffield and UDLA, 

[R] Cacheing of functions from libraries other than the base in Rmarkdown

[Chris Evans]

This question may belong somewhere else, if so, please signpost me and accept 
apologies.

What is happening is that I have a large (for me, > 3k lines) Rmarkdown file 
with many R code blocks (no other code or 
engine is used) working on some large datasets.  I have some inline r like 

   There are `r n_distinct(tibDat$ID)` participants and `r nrow(tibDat)` rows 
of data.

What I am finding is that even if one knit has worked fine and I change 
something somewhere and knit again, the second
knit is often failing with an error like

   n_distinct(tibDat$ID) : could not find function "n_distinct"

This is not happening for functions like nrow() from base R and it mostly seems 
to happen to functions from the tidyverse.

I think what is happening is some sort of cache corruption presumably caused by 
the memory demands.  I am pretty sure I've
seen this before but a long time ago and dealt with it by deleting the files 
and cache folders created by the knit.  That
works now too but as knitting the whole file now takes over 20 minutes, I 
really don't want to have to do that.

I have found that replacing things with base functions fixes the problem every 
time, e.g. replacing `r n_distinct(tibDat$ID)`
with `r length(unique(tibDat$ID))` works fine.  The other workaround is to 
compute what you need for the inline 
computation at the end of the preceding code block, trivial e.g. at the end of 
the preceding code block:

n_distinct(tibDat$ID) -> tmpN
```

and then

  `r tmpN` 

that works fine so I have my workarounds but I guess I have three questions:

1) do others see this?
2) is there some setting that might, assuming my guess about the cause is 
correct, increase some storage somewhere and avert this?
3) if it is a bug, where should I report it (as I'm not sure what is causing 
it!)?

Thanks in advance,

Chris



> sessionInfo()
R version 4.1.1 (2021-08-10)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 20.04.3 LTS

Matrix products: default
BLAS:   /usr/lib/x86_64-linux-gnu/openblas-pthread/libblas.so.3
LAPACK: /usr/lib/x86_64-linux-gnu/openblas-pthread/liblapack.so.3

locale:
 [1] LC_CTYPE=en_GB.UTF-8   LC_NUMERIC=C   LC_TIME=en_GB.UTF-8  
  LC_COLLATE=en_GB.UTF-8 LC_MONETARY=en_GB.UTF-8
LC_MESSAGES=en_GB.UTF-8LC_PAPER=en_GB.UTF-8   LC_NAME=C 
 [9] LC_ADDRESS=C   LC_TELEPHONE=C 
LC_MEASUREMENT=en_GB.UTF-8 LC_IDENTIFICATION=C   

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

other attached packages:
 [1] boot_1.3-28 CECPfuns_0.0.0.9041 janitor_2.1.0   
lubridate_1.7.10forcats_0.5.1   stringr_1.4.0   dplyr_1.0.7 
purrr_0.3.4 readr_2.0.1 tidyr_1.1.3 tibble_3.1.4   
[12] ggplot2_3.3.5   tidyverse_1.3.1 english_1.2-6   pander_0.6.4   


loaded via a namespace (and not attached):
 [1] fs_1.5.0bit64_4.0.5 RColorBrewer_1.1-2  httr_1.4.2 
 tools_4.1.1 backports_1.2.1 utf8_1.2.2  R6_2.5.1   
 rpart_4.1-15Hmisc_4.5-0 DBI_1.1.1  
[12] colorspace_2.0-2nnet_7.3-16 withr_2.4.2 
tidyselect_1.1.1gridExtra_2.3   bit_4.0.4   compiler_4.1.1  
cli_3.0.1   rvest_1.0.1 htmlTable_2.2.1 xml2_1.3.2 
[23] labeling_0.4.2  scales_1.1.1checkmate_2.0.0 corrr_0.4.3
 odbc_1.3.2  digest_0.6.27   readODS_1.7.0   foreign_0.8-81 
 rmarkdown_2.11  base64enc_0.1-3 jpeg_0.1-9 
[34] pkgconfig_2.0.3 htmltools_0.5.2 dbplyr_2.1.1fastmap_1.1.0  
 RJDBC_0.2-8 htmlwidgets_1.5.4   rlang_0.4.11readxl_1.3.1   
 rstudioapi_0.13 farver_2.1.0generics_0.1.0 
[45] jsonlite_1.7.2  magrittr_2.0.1  Formula_1.2-4   Matrix_1.3-4   
 Rcpp_1.0.7  munsell_0.5.0   fansi_0.5.0 
lifecycle_1.0.0 stringi_1.7.4   yaml_2.2.1  snakecase_0.11.0   
[56] grid_4.1.1  blob_1.2.2  crayon_1.4.1
lattice_0.20-44 haven_2.4.3 splines_4.1.1   hms_1.1.0   
knitr_1.34  pillar_1.6.2reprex_2.0.1glue_1.4.2 
[67] evaluate_0.14   latticeExtra_0.6-29 data.table_1.14.0   modelr_0.1.8   
 png_0.1-7   vctrs_0.3.8 tzdb_0.1.2  psy_1.1
 cellranger_1.1.0gtable_0.3.0assertthat_0.2.1   
[78] xfun_0.26   broom_0.7.9 rsconnect_0.8.24
viridisLite_0.4.0   survival_3.2-13 rJava_1.0-4 cluster_2.1.2   
ellipsis_0.3.2


-- 
Chris Evans (he/him)  Visiting Professor, University of 
Sheffield and UDLA, Quito, Ecuador
I do some consultation work for the University of Roehampton 
 and other places
but  remains my main Email address.  I have a work web site 
at:
   https://www.psyctc.org/psyctc/
and a site I manage 

Re: [R] ReadItem: Error

[Bert Gunter]

Did you try infoRDS() ?  It **may** tell you something useful, though
it cannot tell you whether the file is corrupted or not. If you post
its results here, someone **may** be able to tell you something
informative.

That's all I got.

Bert Gunter

"The trouble with having an open mind is that people keep coming along
and sticking things into it."
-- Opus (aka Berkeley Breathed in his "Bloom County" comic strip )

On Sat, Sep 18, 2021 at 9:00 AM Jeff Reichman  wrote:
>
> Anyone see what I might be doing wrong? Corrupted rds file maybe. The error
> would suggest I'm using an older version of R except I'm running both the
> latest RStudio and R versions.
>
> # Load in the tidyverse, raster, and sf packages
> library(tidyverse)
> library(raster)
> library(sf)
>
> # Read the climate data from an rds file
> climate <- readRDS("Datasets/climate_raster.rds")
>
> # Have a look at the variables in the climate data
> colnames(climate)
>
> # Convert to SpatialPixelDataFrame for plotting
> climate_df <- mutate(
>   .data = climate,
>   rasters = map(
> .x = rasters,
> ~ as_tibble(as(.x, "SpatialPixelsDataFrame" %>%
>   unnest(cols = c(rasters))
>
> > climate <- readRDS("Datasets/climate_raster.rds")
> Error in readRDS("Datasets/climate_raster.rds") :
>   ReadItem: unknown type 0, perhaps written by later version of R
>
> __
> R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

[R] ReadItem: Error

[Jeff Reichman]

Anyone see what I might be doing wrong? Corrupted rds file maybe. The error
would suggest I'm using an older version of R except I'm running both the
latest RStudio and R versions.

# Load in the tidyverse, raster, and sf packages
library(tidyverse)
library(raster)
library(sf)

# Read the climate data from an rds file
climate <- readRDS("Datasets/climate_raster.rds")

# Have a look at the variables in the climate data
colnames(climate)

# Convert to SpatialPixelDataFrame for plotting
climate_df <- mutate(
  .data = climate, 
  rasters = map(
.x = rasters, 
~ as_tibble(as(.x, "SpatialPixelsDataFrame" %>%
  unnest(cols = c(rasters))

> climate <- readRDS("Datasets/climate_raster.rds")
Error in readRDS("Datasets/climate_raster.rds") : 
  ReadItem: unknown type 0, perhaps written by later version of R

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] Improvement: function cut

[Leonard Mada via R-help]

Hello Andrew,


I add this info as a completion (so other users can get a better 
understanding):

If we want to perform a survival analysis, than the interval should be 
closed to the right, but we should include also the first time point (as 
per Intention-to-Treat):

[0, 4](4, 8](8, 12](12, 16]

[0, 4](4, 8](8, 12](12, 16](16, 20]


So the series is extendible to the right without any errors!

But the 1st interval (which is the same in both series) is different 
from the other intervals: [0, 4].


I feel that this should have been the default behaviour for cut().

Note:

I was induced to think about a different situation in my previous 
message, as you constructed open intervals on the right, and also 
extended to the right. But survival analysis should be as described in 
this mail and should probably be the default.


Sincerely,


Leonard


On 9/18/2021 1:29 AM, Andrew Simmons wrote:
> I disagree, I don't really think it's too long or ugly, but if you 
> think it is, you could abbreviate it as 'i'.
>
>
> x <- 0:20
> breaks1 <- seq.int (0, 16, 4)
> breaks2 <- seq.int (0, 20, 4)
> data.frame(
>     cut(x, breaks1, right = FALSE, i = TRUE),
>     cut(x, breaks2, right = FALSE, i = TRUE),
>     check.names = FALSE
> )
>
>
> I hope this helps.
>
> On Fri, Sep 17, 2021 at 6:26 PM Leonard Mada  > wrote:
>
> Hello Andrew,
>
>
> But "cut" generates factors. In most cases with real data one
> expects to have also the ends of the interval: the argument
> "include.lowest" is both ugly and too long.
>
> [The test-code on the ftable thread contains this error! I have
> run through this error a couple of times.]
>
>
> The only real situation that I can imagine to be problematic:
>
> - if the interval goes to +Inf (or -Inf): I do not know if there
> would be any effects when including +Inf (or -Inf).
>
>
> Leonard
>
>
> On 9/18/2021 1:14 AM, Andrew Simmons wrote:
>> While it is not explicitly mentioned anywhere in the
>> documentation for .bincode, I suspect 'include.lowest = FALSE' is
>> the default to keep the definitions of the bins consistent. For
>> example:
>>
>>
>> x <- 0:20
>> breaks1 <- seq.int (0, 16, 4)
>> breaks2 <- seq.int (0, 20, 4)
>> cbind(
>>     .bincode(x, breaks1, right = FALSE, include.lowest = TRUE),
>>     .bincode(x, breaks2, right = FALSE, include.lowest = TRUE)
>> )
>>
>>
>> by having 'include.lowest = TRUE' with different ends, you can
>> get inconsistent behaviour. While this probably wouldn't be an
>> issue with 'real' data, this would seem like something you'd want
>> to avoid by default. The definitions of the bins are
>>
>>
>> [0, 4)
>> [4, 8)
>> [8, 12)
>> [12, 16]
>>
>>
>> and
>>
>>
>> [0, 4)
>> [4, 8)
>> [8, 12)
>> [12, 16)
>> [16, 20]
>>
>>
>> so you can see where the inconsistent behaviour comes from. You
>> might be able to get R-core to add argument 'warn', but probably
>> not to change the default of 'include.lowest'. I hope this helps
>>
>>
>> On Fri, Sep 17, 2021 at 6:01 PM Leonard Mada > > wrote:
>>
>> Thank you Andrew.
>>
>>
>> Is there any reason not to make: include.lowest = TRUE the
>> default?
>>
>>
>> Regarding the NA:
>>
>> The user still has to suspect that some values were not
>> included and run that test.
>>
>>
>> Leonard
>>
>>
>> On 9/18/2021 12:53 AM, Andrew Simmons wrote:
>>> Regarding your first point, argument 'include.lowest'
>>> already handles this specific case, see ?.bincode
>>>
>>> Your second point, maybe it could be helpful, but since both
>>> 'cut.default' and '.bincode' return NA if a value isn't
>>> within a bin, you could make something like this on your own.
>>> Might be worth pitching to R-bugs on the wishlist.
>>>
>>>
>>>
>>> On Fri, Sep 17, 2021, 17:45 Leonard Mada via R-help
>>> mailto:r-help@r-project.org>> wrote:
>>>
>>> Hello List members,
>>>
>>>
>>> the following improvements would be useful for function
>>> cut (and .bincode):
>>>
>>>
>>> 1.) Argument: Include extremes
>>> extremes = TRUE
>>> if(right == FALSE) {
>>>     # include also right for last interval;
>>> } else {
>>>     # include also left for first interval;
>>> }
>>>
>>>
>>> 2.) Argument: warn = TRUE
>>>
>>> Warn if any values are not included in the intervals.
>>>
>>>
>>> Motivation:
>>> - reduce risk of errors when using function cut();
>>>
>>>
>>> Sincerely,
>>>
>>>
>>> Leonard
>>>
>>> __
>>> R-help@r-project.org 

[R-es] Traducción de fechas

[Jose Miguel Contreras]

Hola

Una pregunta tonta

¿Cómo hago para que me coja las fechas en inglés si lo tengo configurado en 
español?
Ejemplo

Si hago:
> as.Date("Octubre 01, 2020",format="%B %d, %Y")
[1] "2020-10-01”

Funciona

Pero lo necesito en inglés
> as.Date("October 01, 2020",format="%B %d, %Y")
[1] NA



Gracias


> El 14 sept 2021, a las 12:00, r-help-es-requ...@r-project.org escribió:
> 
> Envíe los mensajes para la lista R-help-es a
>   r-help-es@r-project.org
> 
> Para subscribirse o anular su subscripción a través de la WEB
>   https://stat.ethz.ch/mailman/listinfo/r-help-es
> 
> O por correo electrónico, enviando un mensaje con el texto "help" en
> el asunto (subject) o en el cuerpo a:
>   r-help-es-requ...@r-project.org
> 
> Puede contactar con el responsable de la lista escribiendo a:
>   r-help-es-ow...@r-project.org
> 
> Si responde a algún contenido de este mensaje, por favor, edite la
> linea del asunto (subject) para que el texto sea mas especifico que:
> "Re: Contents of R-help-es digest...". Además, por favor, incluya en
> la respuesta sólo aquellas partes del mensaje a las que está
> respondiendo.
> 
> 
> Asuntos del día:
> 
>   1. Re: Particionar bases con split. (juan manuel dias)
> 
> --
> 
> Message: 1
> Date: Mon, 13 Sep 2021 08:12:40 -0300
> From: juan manuel dias 
> To: Carlos Ortega 
> Cc: Lista R 
> Subject: Re: [R-es] Particionar bases con split.
> Message-ID:
>   
> Content-Type: text/plain; charset="utf-8"
> 
> Gracias Carlos!
> 
> El sáb., 11 de septiembre de 2021 10:10, Carlos Ortega <
> c...@qualityexcellence.es> escribió:
> 
>> Hola,
>> 
>> Para la parte de la extracción de "p12" del nombre de la variable, esta es
>> una forma sencilla de hacerlo.
>> 
>> #---
>>> library(dplyr)
>>> library(stringr)
>>> 
>>> df <- data.frame(
>> + ute.p12 = rnorm(100),
>> + suteba.p12 = rnorm(100)
>> + )
>>> 
>>> 
>>> mynames <- names(df) %>%
>> + word(., 2, sep = fixed('.'))
>>> mynames
>> [1] "p12" "p12"
>> #
>> 
>> Gracias,
>> Carlos Ortega
>> www.qualityexcellence.es
>> 
>> 
>> 
>> El vie, 10 sept 2021 a las 14:54, juan manuel dias ()
>> escribió:
>> 
>>> Hola, como andan! Estoy trabajando con una base que está en formato .sav,
>>> y
>>> necesito particionarla en muchos data frames distintos en función de una
>>> variable factor, y a cada partición guardarla en formato .sav y/o xlsx, y
>>> que cada base esté nombrada con el factor con la cuál generé la partición.
>>> La parte de levantar la base y que cada partición quede guardada en una
>>> lista esta resuelto con split de r base.
>>> 
>>> El tema que veo es que me guarda cada data frame y en cada nombre de
>>> variable le agrega el nombre del factor por el cual genere el split. Por
>>> ejemplo, la variable es "p12" y le agrega "ute.p12", "suteba.p12", etc.
>>> Querría sacar ute. y suteba. No sé si puede resolver dentro del split o
>>> directamente usar dplyr.
>>> 
>>> Y por otro lado, no encuentro en haven como hacer para que al levantar una
>>> base .sav, las variables tomen el nombre de las etiquetas. Por ejemplo,
>>> "p12" es nombre de variable y la etiqueta es "edad", quiero que tomé
>>> "edad"
>>> como nombre.
>>> 
>>> Muchas gracias! Saludo, Juan.
>>> 
>>>[[alternative HTML version deleted]]
>>> 
>>> ___
>>> R-help-es mailing list
>>> R-help-es@r-project.org
>>> https://stat.ethz.ch/mailman/listinfo/r-help-es
>>> 
>> 
>> 
>> --
>> Saludos,
>> Carlos Ortega
>> www.qualityexcellence.es
>> 
> 
>   [[alternative HTML version deleted]]
> 
> 
> 
> 
> --
> 
> Subject: Pié de página del digest
> 
> ___
> R-help-es mailing list
> R-help-es@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-help-es
> 
> 
> --
> 
> Fin de Resumen de R-help-es, Vol 151, Envío 9
> *

___
R-help-es mailing list
R-help-es@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-help-es