-
Notifications
You must be signed in to change notification settings - Fork 286
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
read_csv fails to guess type of integer column #1094
Comments
This is actually by design, readr never guesses columns are of type integer. In earlier versions of readr we did guess columns were of type integer, however this caused numerous issues in practice when the first X number of rows were integers, with floating point numbers later in the file. Since all 32 bit integers will fit in a 64 bit double this ensures we don't lose information. If you know you want |
Makes sense. However, if newer versions of readr don't guess integer, that is important info that should be added to the documentation. Is it okay if I open a documentation issue? |
Sure, it would need to be added at https://github.com/tidyverse/readr/blob/master/vignettes/readr.Rmd#L128. |
Shouldn't it go into the man page of |
Hi, wouldn't it be most consistent if an option like |
I came across this because I too didn't know why integers weren't guessed by read_csv() and I wanted them to be :-) My use case is that I'm reading in tables with ID columns from a standard format (OMOP) that other code expects to be integer and it causes later join failures if they are double. Found this solution on stackoverflow that seems to work for me. (Although I do feel a little nervous deliberately circumventing a design feature ...) A little more explicit documentation in the man page of read_csv would be useful :-) |
The data has 73 rows and all entries in the last column are integers. Yet
read_csv
guessescol_double()
.Example:
Results in:
Last line should be
Langs = col_integer()
.This is using up-to-date readr from CRAN and R version 3.6.3 (2020-02-29).
The text was updated successfully, but these errors were encountered: