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

The R language, for programmers

johndcook.com

Post reply on HN
Print view View original

31–40 of 79 posts

Re: The R language, for programmers

#31

Post by platz »

mbq wrote: post #29
chuckcode wrote: post #25

Earlier quoted context omitted.

Python has better and better support for R with Rpy2 and R like data frames with Pandas, which is helping me take advantage of the incredibly useful analysis libraries in R. Also note that loops are slow enough that it is really worth learning the *apply() functions in R to avoid iterating over collections. For a relatively in depth explanation check out Hadley Wickham's book http://adv-r.had.co.nz/Functionals.html

*apply functions are loops underneath -- they only look better and save you time possibly wasted on growing some dynamically sized output structure. The way of solving slow loop in R is to find package which implements it in C/Fortran (or write your own in case there is none).

I believe there is also the Rcpp package which lets you write inline compiled c++

Re: The R language, for programmers

#32

Post by redacted »

fallat wrote: post #30

Haskell is better than R, for both programmers and data analysts.

Could you expand on why? I'll be starting a data-heavy side project and have meant to make an effort with Haskell for a while

I always thought that R is fairly unmatched in both breadth and depth for statistical work and general data analysis, with the Python stack in second (e.g., numpy+scipy+pandas+...).

Re: The R language, for programmers

#34

Post by ggrothendieck »

minimaxir wrote: post #5

The biggest "gotcha" for learning R as a programmer is that R interprets character vectors of data frames as factor vectors by default , which will usually break something in your code. If you're learning R, learn to use dplyr for data manipulation and ggplot2 for plotting. Both will save you a lot of time.

To be clear this applies to data frames, not the language as a whole. If you are creating a data frame by reading in data then `read.table(...whatever..., as.is = TRUE)` will read in character columns as character strings and not as factors. `data.frame()` has a `stringsAsFactors` argument which can be set to `FALSE` and one can change the global default with: `options(stringsAsFactors = FALSE)` .

Re: The R language, for programmers

#35

Post by epistasis »

Alupis wrote: post #2

I actually quite like the R language. A buddy of mine is in his University's PoliSci program and one of the requirements is to learn R for statistical and trend analysis. He could not stop complaining until I offered to help him learn it by learning it with him. After doing his first assignment, we were both impressed with what could be easily done in R to visualize data. I think he now realizes how useful of a tool…

I actually really like it too. The programming language features of it are quite different from what's going on in a Java/C++/C# world, but they are super convenient.

Argument matching is really amazing and useful for prototyping. No doubt there's a penalty, but it's exactly the type of power that's needed to build expressive and useful reusable components with rapidly changing designs. And pattern matching like that really helps with the REPL because it allows far faster exploration with fewer keystrokes. Best programming practice in library code would be to have things more fully fleshed out however.

Re: The R language, for programmers

#36

Post by psychometry »

elliott34 wrote: post #18

I love pandas much more than R but GOD I love Rstudio. Such a great IDE. Rstudio server, actually. My equivalent is running ipython notebook on an ec2 instance, which....is fine, but is a lot of scrolling.

RStudio is great for R files, but has awful memory leaks if you're using it for RSweave/knitr documents. I weaned myself off RSTudio onto Sublime+Various Packages+R Console and couldn't be happier.

Re: The R language, for programmers

#37

Post by rcthompson »

lispm wrote: post #27
rcthompson wrote: post #15

Earlier quoted context omitted.

You can think of the lazily evaluated arguments feature a lot like lisp macros. Basically, any function in R can either get the value of its arguments (i.e. acting like a regular function) or it can get the unevaluated expression passed for that argument (i.e. acting like a lisp macro). So in your "do.stuff" example, it's not a matter of special scoping, per se. The do.stuff function is actually getting the symbols "…

That would be a FEXPR in Lisp, not a macro. In most actually used Lisp dialects, FEXPRs have been replaced with macros.

Ah, yes, you're correct. Regardless of how an R function treats its arguments, it returns a result directly, never an unevaluated expression like a lisp macro. I didn't even know about FEXPRs (my main lisp is emacs lisp).

Re: The R language, for programmers

#38

Post by craigching »

mbq wrote: post #29
chuckcode wrote: post #25

Earlier quoted context omitted.

Python has better and better support for R with Rpy2 and R like data frames with Pandas, which is helping me take advantage of the incredibly useful analysis libraries in R. Also note that loops are slow enough that it is really worth learning the *apply() functions in R to avoid iterating over collections. For a relatively in depth explanation check out Hadley Wickham's book http://adv-r.had.co.nz/Functionals.html

*apply functions are loops underneath -- they only look better and save you time possibly wasted on growing some dynamically sized output structure. The way of solving slow loop in R is to find package which implements it in C/Fortran (or write your own in case there is none).

> * apply functions are loops underneath

Yes, but aren't they native loops underneath? I've seen it said both ways, that * apply is faster than R loops and that *apply isn't faster than R loops. Would be nice if someone could definitively answer the question and back it up with some stats! :)

EDIT: Thanks chuckcode, sibling post to this, I stand corrected :)

Re: The R language, for programmers

#39

Post by michaeltoth »

fallat wrote: post #30

Haskell is better than R, for both programmers and data analysts.

It's going to be harder to do just about anything related to data analysis in Haskell than in R. In R I can load a dataset, do some formatting, and produce a well designed plot in fewer than 5 lines of code. Haskell might run faster, and it's certainly more versatile, but for data analysis it isn't even comparable.

Re: The R language, for programmers

#40

Post by craigching »

jmount wrote: post #11

To my mind some of R's plusses are data frames and the ability to indicate missing values in vectors of any type. Some of the weird stuff is the lazy evaluation of arguments, the ability to know the names of variables bound to function arguments, and the ability to snoop up the environment stack. Some distinct minuses are the changing of types (dropping of dimensions on select), semi-reserved terms, and c()'s squashi…

And plotting, especially ggplot2!
Post reply on HN