14 comments

[ 0.27 ms ] story [ 66.1 ms ] thread
> as.tibble(cbind(x,y,z)) %>% na.omit()

Why on earth would anyone write that instead of na.omit(as.tibble(cbind(x,y,z)))? Baffles me.

...reading from left to right for starter?

It's why I adore %>% as code gets reads as a sequence of step-by-step instructions, of one forcing a reader to constantly keep switching between left-to-right and right-to-left.

f(x,y) reads "f of x and y". How do you say x %>% f(y) in words?
Since "%>%" is the pipe operator I would guess "x pipe f of y", or "x pipe to f of y"
Hadley Wickham suggests using "then" for pipes. SO we take object x, then perform f(y) with it.
Hi, author here. I just find it much more intuitive, like unix pipes, or Clojure's threading macros. Nested calls are more confusing to me. Though it should have probably been better as cbind(...) %>% as.tibble() %>% na.omit...
Alternatively,

    x %>%
      bind_cols(y, z) %>%
      as.tibble() %>%
      na.omit()
Makes the order of execution a little clearer (and uses more dplyr conventions). I still nest functions when working interactively with a REPL, but for code I'll have to reread in the future, the pipes save me much head scratching. Death to the pyramid of doom.
For emphasis, bind_cols is a dplyr function (meaning it gets the speed boost from using Rcpp, albeit not much difference when adding a few columns), while cbind is a base function which does not.

dplyr nowadays obsoletes most of the basic building blocks of data frame construction, although they are hidden in the docs.

thank you for sharing this! i'd like to try and recreate this in R.
Hi, author here. You can use the code in there as a starting point, it's rather simple!
For the observation toward the end that compressed files seem highly uniform, this makes sense intuitively. If there were any visible patterns, that would imply that the data is further compressible, which would mean the compressor didn't do it's job very well.