-
Notifications
You must be signed in to change notification settings - Fork 79
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
Numbers that should be zero are displayed in scientific notation #479
Comments
I can confirm this is also true in v2. This is odd to me given that we spent so much effort on thinking about how many digits to display. Does only displaying 4 for x make sense given that the values start with 3 digits to the right of the decimal? @michaelquinn32 |
Scientific notation appearing like that is a product of using floating point numbers. It's bigger than I'll keep thinking about it, but I'm not sure of a way to get it right:
Thanks for bringing this up! |
I think we just need to show 0 in these cases, which is what happens when you knit. We don't want to change the underlying data that is passed out of skimr but I think we want to display the data in expected ways. Among other things it is strange to see just one number with scientific notation in the column. |
I guess the issue is that some numbers probably should appear in scientific notation and some shouldn't, then the question is how to control that. I'm wondering if this is a situation where the user should have to take some action, which could range from creating a custom statistic to having some kind of setting that could be defined. But I worry about opening the door to too many settings. Though I do agree that we don't want to force the user to make the underlying values rounded. |
I'm putting help wanted on this since we'd be willing to look at a contributed solution. |
This is something that comes up in the pillar release notes: Small numbers can be meaningfully different. I believe that it's a mistake to round.
The more I think about it, the more I believe that we should be pushing as much printing-related logic as possible into pillar. This seems to be the general TV approach. And it also means that a PR in this case might not be appropriate. |
I think the key phrase there is "can be". So maybe add an optional argument specifying the threshold at which to round? |
I think the option then is to open a pillar PR where you can control scientific notation. In base R, that would be something like There is a separate discussion on this in the Rstudio forum: |
Part of the issue is if you only want to do this for print or if you really want to round the data in the skimr object. If you are not going to do further calculations with the object and therefore don't care about the accuracy you could write a custom skim that rounds. |
This is a good point. For my use case, at least, I'd like the underlying data to be unchanged and just the printing to be rounded. |
@ben-schwen Were you waiting on a response from me on this? |
So I would not be in favor of adding arguments. That defeats the purpose of a simple function. One possibility would be to do something like add a special function the way we have with |
I think something like |
That’s a bit of a different issue than the scientific notation but if we were making print method options maybe there could be something like that. We could also look at what knitr is doing.
… On Jan 27, 2021, at 11:03 AM, Jeffrey Girard ***@***.***> wrote:
I think something like print(skim(df), digits = 3) would be nice.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub <#479 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFYI7LCEHK4OCRSPZJUK33S4A2NDANCNFSM4IFTCWKA>.
|
This may be an issue with R as opposed to
skimr
, but it always bothers me. I'd appreciate help if you have any. Basically, numbers that should be essentially zero are displayed in scientific notation. Is there some way to avoid this other than theround()
function? Here is an example:The text was updated successfully, but these errors were encountered: