option to disable new print method color scheme

[slonik-az]

Recently, tibble print method started printing some digits in pale grey making output hard to read. Also, a concept of three significant digits for integers makes no sense.

What option should I set to get back the old monochrome print method that does not highlight significant digits?

Thanks,
--Leo

[krlmlr]

Thanks for your feedback. The colored output attempts to highlight important parts while still printing everything. I wonder why it is important to you to read the exact values, maybe a separator every three digits would help?

If you prefer monochromatic output, you can set the option "crayon.enabled" to FALSE or turn off the colored console in RStudio. Both options will turn off colored output in other packages.

[slonik-az]

@krlmlr : Thanks for a quick reply and suggestions. In general, I like RStudio console colors but I have an issue with readability of pale-grey digits in new tibble printed output. I do not see rationale in highlighting first three digits of a long integer leaving the rest in pale grey. A zebra pattern with 3 digits long stripes would be better, i.e. 123456789.

In any case, it would be super-useful to have an option (like tibble.signif=FALSE) to disable highlighting of significant digits altogether. Right now I reverted back to tibble-1.3.4 but it is only a short-term solution.

Thanks, --Leo

[MaximilianBernkopf]

First of all thanks for keeping up the awesome work.

I noticed something else regarding the new print method.
Under version 1.3.4 the columns were perfectly aligned:

But now it's getting a little hard to read:

Is there some intention behind that?

Thanks in advance.

[whanrott]

Further to this issue... The code which recreates this issue for me is:

data_frame(numbers = c(1L,10L,100L,1000L), text = letters[1:4])
data_frame(numbers = c(1,10,100,1000), text = letters[1:4])
data_frame(text = letters[1:4], numbers = c(1L,10L,100L,1000L))
data_frame(text = letters[1:4], numbers = c(1,10,100,1000))

The result looks like this:

My version details are:

platform       x86_64-pc-linux-gnu         
arch           x86_64                      
os             linux-gnu                   
system         x86_64, linux-gnu           
status                                     
major          3                           
minor          4.3                         
year           2017                        
month          11                          
day            30                          
svn rev        73796                       
language       R                           
version.string R version 3.4.3 (2017-11-30)
nickname       Kite-Eating Tree

I'm using dplyr version 0.7.4

[iacobus42]

I too am running into issues with the new print method causing poor alignment issues. I have a few cases where the variable name is much shorter than the variable values (e.g., ID type variables) and this can cause alignment issues.

The following prints okay:

tibble(
  id = as.character(round(runif(10, 10^14, 10^15 - 1))),
  height = rnorm(10),
  weight = rnorm(10)
)

but when the ordering is changed, it does not print correctly:

tibble(
  height = rnorm(10),
  weight = rnorm(10),
  id = as.character(round(runif(10, 10^14, 10^15 - 1)))
)

It gets even more broken pretty quickly. Using a plausible data set:

tibble(
  id = as.character(round(runif(10, 10^14, 10^15 - 1))),
  height = rnorm(10),
  weight = rnorm(10),
  bmi = weight / height^2,
  female = rbinom(10, 1, 0.5),
  phone_number = as.character(round(runif(10, 10^10, 10^11 - 1))),
  runs = rbinom(10, 1, 0.5),
)

Indeed, this is visible even with something as simple as making mt_cars into a tibble and printing:

The UDJudgeRatings is even worse:

Will these be an option to completely disable this "pretty printing" of the data? It seems somewhat broken.

[billdenney]

@krlmlr, In response to your comment above "I wonder why it is important to you to read the exact values, maybe a separator every three digits would help?"

I often need to read subject identifiers for clinical trials which can be a string of 3 to 9 digits (typically), and I then need to compare those numbers to numbers generated elsewhere. Precise readability is important for me, too.

Also, the readability of the light gray on white motif will impact people who have vision difficulty with low contrast images (http://www.allaboutvision.com/eye-exam/contrast-sensitivity.htm).

In most scenarios, I like having the added color help me quickly differentiate between various parts of the code and output, but having granular control of when it applies and when it doesn't would be beneficial.

[hadley]

Mostly duplicate of r-lib/pillar#76, although there are a bunch of issues in here.

[eipi10]

I see this issue is closed, but I also find that the new tibble print method with numbers partially greyed out makes output hard to read. Below is an example.

I have to admit I did a doubletake when I saw @krlmr's comment above "I wonder why it is important to you to read the exact values..." I'd turn that around and ask why is it important to make data output harder to read? The new print method just seems like a bizarre choice. For now I've rolled back to the previous version of tibble, but that's obviously not a long-term solution. I realize I can turn off the new printing style by changing the crayon.enabled option, but it would be better to have a reasonable default in the first place.

[krlmlr]

There'll be an option to turn off highlighting altogether, and we should also work on more granular control.

The highlighting aims at making the important information easier to read while still including "everything". Of course if the number is in fact a subject identifier encoded as a number, as in Bill's case, all digits are important. I certainly missed that part.

[jennybc]

The "number that should not be formatted as a number" comes up a lot in spreadsheets too. I'm not sure if this has any practical implications but it's a connection worth noting. Product codes, social security numbers, etc. might look like numbers, but they're really more like strings over a numeric alphabet. In readxl, it's a constant effort when coercing to character to prevent the use of scientific notation or spurious decimal places.

[krlmlr]

Maybe we just need an S3 class for sequences of digits that are not to be interpreted as numbers? Need to make sure that dplyr maintains this class in all verbs.

Detecting these numbers automatically (e.g. when importing spreadsheets) is a whole different class of problem, I assume.

[jennybc]

It's kind of interesting to ponder the extreme position that any such variable should really be stored as character. Then it becomes a coercion problem, not a printing problem.

I'm not sure we should do anything about this, at this point. I just think it's helpful to recognize the phenomenon.

[krlmlr]

In theory, yes. In practice, always storing as character wastes storage and computation time, by an order of magnitude.

[AshesITR]

@krlmlr Pardon me for my ignorance, but don't you have options(pillar.subtle = FALSE) precisely for omiting the grey-out effect?

[krlmlr]

Calling options(pillar.subtle_num = FALSE) should now give the desired effect for numbers only, options(pillar.subtle = FALSE) turns off greying for all elements (header, footer, row names).

[github-actions]

This old thread has been automatically locked. If you think you have found something related to this, please open a new issue and link to this old issue if necessary.