Changing digits in skimr

[BlueJ]

I am using the new version of skimr in R Notebook. The help file says that I can limit the number of digits:

"You can change the number of digits shown in the columns of generated statistics by changing the skimr_digits chunk option"

I take this to mean I would include e.g. skimr_digits=4 in the top of my chunk:

{r skimr_digits = 4}

However when I do this I still get very long digits in my tables.

Has anyone else come across this? What am I missing?

Thanks in advance

[nirgrahamuk]

seems to me that the chunk option used as you show, does indeed have an effect when you hit the big old Knit button, but not when you are running a chunk interactively. Not ideal eh ?

[BlueJ]

I just checked but I still get long numbers in the knitted output. I am knitting to html, assume that shouldnt make a difference (have never mastered knitting to pdf, its on the list).

Thanks though

[nirgrahamuk]

as I tested mine by knitting to html,could it be a package version issue ?

packageVersion("knitr")
[1] ‘1.28’
packageVersion("skimr")
[1] ‘2.1’

[cderv]

It also work for me when rendering

---
title: "Test"
output: html_document
---

```{r, skimr_digits = 1}
skimr::skim(iris)
```

But note for html_notebook because the chunk option seems to not be taken into account by the IDE when running chunk.
It could be an IDE issue here... or a feature in skimr not working for html_notebook format.

This seem to be because, in html_notebook format, knit_print is not called. Just a normal print of skimr object...

[BlueJ]

@nirgrahamuk

packageVersion("skimr")

right - that probably explains this. So if I moved out of notebook and into markdown in might work? and if I ever manage to get my pdf knit working?

I will update my packages just in case but I'm not too far out I think
packageVersion("knitr")
[1] ‘1.27’

packageVersion("skimr")
[1] ‘2.0.2’

[nirgrahamuk]

@BlueJ

So if I moved out of notebook and into markdown in might work?

yes, thats how I interpret the info from @cderv

[cderv]

Yes, if you use html_document for your report or even pdf_document and render the Rmd file as a whole it should work as expected.

Maybe a bug or feature request should be open on the IDE for this...

[BlueJ]

I have tested this a bit more myself. If I just use skim, or my tailored skim, then it renders fine with the skimr_digits specified into html in both notebook AND markdown. So thats good.

In the previous incarnation, I had been using knit_print to render my table:

SDWideSkim<-my_skim(SD19WithSciencePlot) %>% yank ("numeric") %>% regulartable() %>% autofit() %>% width(width=1)

knit_print(SDWideSkim)

(you may notice from my code I don't really know what I'm doing but this has been working). I get a nice table. Skimr_digit only works if I just use

my_skim(SD19WithSciencePlot) %>% yank ("numeric")

It looks like if I try to pipe the output into a flextable object then it ignores the skimr digits.

It does say in the vignette

For documents rendered by knitr , the package provides a custom knit_print method. To use it, the final line of your code chunk should have a skim_df object.

So perhaps the additional pipe means this doesnt work.

This isn't a massive problem as now that its defaulting to knit_print (which I think is new), it looks quite nice in markdown. However, in notebook, the rendered table is not very well formatted:

In markdown the same table from the same code and source looks like this:

I think this is due to your earlier point

This seem to be because, in html_notebook format, knit_print is not called. Just a normal print of skimr object...

I tried piping the skim to knit_print in notebook but it didn't change the formatting.

I guess I can manage this by using Markdown instead. May be worth noting for others and in the manual that you can only see the effects of skimr_digit in the rendered doc and not in notebook, and that you can not pipe the output on - at least not into flextable. Explicitly noting the print difference between Notebook and Markdown might be useful too. I don't think thats noted in the vignette but it may be obvious to those who understand the difference better than I