Skip to content
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

Ideas/plans for additional types #31

Open
1 of 3 tasks
scottporter opened this issue Mar 23, 2024 · 0 comments
Open
1 of 3 tasks

Ideas/plans for additional types #31

scottporter opened this issue Mar 23, 2024 · 0 comments

Comments

@scottporter
Copy link

scottporter commented Mar 23, 2024

Please specify whether your issue is about:

  • a possible bug
  • a question about package functionality
  • a suggested code or documentation change, improvement to the code, or feature request

I like the idea of csvy. I didn't want to invent my own metadata format, so I've been using the yaml file, even though I'm writing the data with different packages (readr, sparklyr, arrow).

However, I realized that the limitation of the column types can get me into trouble. If I have an integer that can't be represented with a 32 bit integer, in R I'll need to store it as a type that can (likely using bit64 or arrow). Those will save out and back in as strings, which is better than several other alternatives of what could happen (that would end up with mangled numbers). But it would be nice to have a better way to deal with them. I imagine that a csvy file with a 64 bit integer saved from python would call that an integer... so from the point of view of having this be a format that is easy to exchange it's not ideal.

Has there been any thought for how to handle extended numeric types for additional precision that we're more commonly have to deal with now?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant