Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Zen of R

gist.github.com

Post reply on HN
Print view View original

11–20 of 28 posts

Re: The Zen of R

#11

Post by jacobolus »

jacobolus wrote: post #9

In some ways this is better, and in others it is much worse. Using named constants instead of magic numbers, and breaking up complex logic into simpler named parts is a huge win for readability/maintainability, as any programmer quickly learns. The big one liner would be a lot nicer in about 3-4 chunks. I’d rewrite this example as something like: num.steps [I’m not an R guy, so that might not be the most typical styl…

Aside: One of the things that I really don’t like about R coming from a background in other programming languages is that a function is evaluated before its arguments; i.e. an expression passed as a parameter to a function is not a value but is an implicit lambda, to be evaluated multiple times somewhere inside the function.

For example:

  replicate(2, rnorm(2))
creates a 2x2 matrix of independent random values. Whereas:

  x
Instead creates a 2x2 matrix with a single random value for each row, repeated across all columns. And so if you want to decompose it, you need to do:

  x
Which will re-call x twice inside the replicate function.

Re: The Zen of R

#12

Post by psb217 »

In Matlab, where one is generally compelled (for better or worse) to think in terms of array operations, the obvious code would be:

plot(mean((cumprod(randn(100,1000) .* 0.03) .* 15))

Well, that is assuming one wants a line plot of the mean value of the "location" at each time point across the population of walks. Personally, I find R's rather idiosyncratic approaches to data handling and function wrangling a bit hard to digest.

Re: The Zen of R

#13

Post by steve19 »

I love R, but it can be frustrating to code with and learn. Some of its datatypes are immensely powerful but work in mysterious ways. It allows you to manipulate expressions in a LISP macro-like fashion which, when used badly by library authors, can make many things appear magical (and inconsistant). There are many inconsistencies in the standard library because of different programming paradigms used (for example (s|m|t|r)apply() vs. Map() and filtering with df$col[] vs. subset() vs. Filter() ).

Yet I love writing code in it. So much can be done in so little code. I am always amazed at how little code I write to accomplish a task.

The RStudio IDE ( http://rstudio.org/ ) is a very pleasant environment to write code in.

Re: The Zen of R

#14

Post by steve19 »

I love R, but it can be frustrating to code with and learn. Some of its datatypes are immensely powerful but work in mysterious ways. It allows you to manipulate expressions in a LISP macro-like fashion which, when used badly by library authors, can make many things appear magical (and inconsistant). There are many inconsistencies in the standard library because of different programming paradigms used (for example (s|m|t|r)apply() vs. Map() and filtering with df$col[] vs. subset() vs. Filter() ).

Yet I love writing code in it. So much can be done in so little code. I am always amazed at how little code I write to accomplish a task.

The RStudio IDE ( http://rstudio.org/ ) is a very pleasant environment to write code in.

Re: The Zen of R

#15

Post by tobiasSoftware »

jacobolus wrote: post #9

In some ways this is better, and in others it is much worse. Using named constants instead of magic numbers, and breaking up complex logic into simpler named parts is a huge win for readability/maintainability, as any programmer quickly learns. The big one liner would be a lot nicer in about 3-4 chunks. I’d rewrite this example as something like: num.steps [I’m not an R guy, so that might not be the most typical styl…

Nice! I think you found the happy medium between the OPs two methods. His first is too long which creates more dependency on being able to read the language and his second is too short which creates more dependence on knowing the functions he's working with. It's very interesting to me as I study readability quite a bit: both long and short coding styles aren't as good as medium.

Re: The Zen of R

#16

Post by radikalus »

This is slick...but:

How often do you want to generate random walks of this type where the variance of the process isn't dependent on its current level?

Observe that, as you increase the standard deviation of the random normal (to even .1), your "random walk" always walks to zero.

I don't mean to be a beady-eyed-pterodactyl but, as cool as clever one-liners sometimes are, often they solve toy problems. I say this as someone who loves R and uses it everyday and constantly is forced to brute-force with ugly inlined Rcpp code. (Which is fine)

Re: The Zen of R

#17

Post by choffstein »

Zen? This is madness!

In my mind, Matlab's (Octave's) array based programming makes sense. This? This does nothing that I expected it to do!

replicate seems to pretty randomly takes a function. Is that an R thing? I think what confuses me most is that there is nothing about this syntax that tells me that "cumprod (rnorm (1000, 1, 0.03))" hasn't already been evaluated! I could not, for the life of me, figure out why replicate didn't just create 100 exact copies. For example, why does replicate(...) evaluate, but the internals don't? This is driving me crazy!

Re: The Zen of R

#18

Post by cop359 »

jacobolus wrote: post #9

In some ways this is better, and in others it is much worse. Using named constants instead of magic numbers, and breaking up complex logic into simpler named parts is a huge win for readability/maintainability, as any programmer quickly learns. The big one liner would be a lot nicer in about 3-4 chunks. I’d rewrite this example as something like: num.steps [I’m not an R guy, so that might not be the most typical styl…

You're absolutely on track here

The way he did it is nice and minimal, and in 2 months when you go back to change something you will have no idea what you did.

I've had to do a few things in R and I always dread revisiting my code. Half the time it's easier and faster to just rewrite everything.

Re: The Zen of R

#19

Post by bedatadriven »

jacobolus wrote: post #11
jacobolus wrote: post #9

In some ways this is better, and in others it is much worse. Using named constants instead of magic numbers, and breaking up complex logic into simpler named parts is a huge win for readability/maintainability, as any programmer quickly learns. The big one liner would be a lot nicer in about 3-4 chunks. I’d rewrite this example as something like: num.steps [I’m not an R guy, so that might not be the most typical styl…

Aside: One of the things that I really don’t like about R coming from a background in other programming languages is that a function is evaluated before its arguments; i.e. an expression passed as a parameter to a function is not a value but is an implicit lambda, to be evaluated multiple times somewhere inside the function. For example: replicate(2, rnorm(2)) creates a 2x2 matrix of independent random values. Wherea…

R does have call-by-need semantics, like (an impure) Haskell, but that's not why replicate's second argument gets evaluated multiple times:

  replicate
The replicate function uses R's compute-on-the-language to construct a new function that has expr as its body.

A closure's argument will be evaluated at most once.

Re: The Zen of R

#20

Post by minikomi »

steve19 wrote: post #13

I love R, but it can be frustrating to code with and learn. Some of its datatypes are immensely powerful but work in mysterious ways. It allows you to manipulate expressions in a LISP macro-like fashion which, when used badly by library authors, can make many things appear magical (and inconsistant). There are many inconsistencies in the standard library because of different programming paradigms used (for example (s…

What sort of tasks have you found where it really shines?
Post reply on HN