This is a potential fix for: csgillespie/efficientR#282
code in Section 5.3.1:
voyages_readr = readr::read_tsv(fname)
generates below output.
There seems to be parsing errors at rows 1023,1025 and so on(this aligns with what @engineerchange has mentioned in csgillespie/efficientR#282 ). Not exactly sure why the current version in the book has parsing error at 2841 row. This row seems fine when I run now.
So, I have updated the markdown comments and code appropriately below comparing read.() VS read_() for offending value at row 1023. The read.() decides hired column as char, whereas read_() decides hired column as logical since the first 1000 row values of hired column are NAs.
Note: read.() interpretation of hired column as char* aligns with the intended classes of the VOC data frame that I found at the link here
@Robinlovelace Please review and let me know your thoughts.
This is a potential fix for: csgillespie/efficientR#282
code in Section 5.3.1:
generates below output.
There seems to be parsing errors at rows 1023,1025 and so on(this aligns with what @engineerchange has mentioned in csgillespie/efficientR#282 ). Not exactly sure why the current version in the book has parsing error at 2841 row. This row seems fine when I run now.
So, I have updated the markdown comments and code appropriately below comparing read.() VS read_() for offending value at row 1023. The read.() decides hired column as char, whereas read_() decides hired column as logical since the first 1000 row values of hired column are NAs.
Note: read.() interpretation of hired column as char* aligns with the intended classes of the VOC data frame that I found at the link here
@Robinlovelace Please review and let me know your thoughts.