4 ms·
The article provides a very good example in support of the argument domain specific languages to help you crank out domain specific code. I like R and use it. B
by T_S_ 16y ago
The article provides a very good example in support of the argument domain specific languages to help you crank out domain specific code. I like R and use it. But I also code my own methods (in haskell these days, but that's not the main point). Before you go and build your company's code base around R realize the following:
1) The primary use case for R is by academics and students comparing various methods on various data sets accessible through R.
2) The code is not really designed with superb reliability in mind. I have debugged a contributor's fortran code and sent in a patch that never appeared in the R code base. The bug remains. Professors often don't support code all that well. Don't blame them. Support is left as an exercise.
3) There are no assurances about the scalability of any particular routine--even if the algorithm scales in theory.
Do try R. It's good. But don't think SAS and the like will disappear. They cater to the production requirements of big companies. And don't use R as an excuse not to write your own production code.
- thangalin 16y ago1) With the integration of R and PostgreSQL (PL/R), this might change. For example, calculate the area of a spherical complex polygon on Earth using PL/R: CREATE FUNCTION plr_polygon_area( latitude double precision[], longitude double precision[]) $BODY$ areaPolygon( cbind( longitude, latitude ) ) $BODY$ LANGUAGE 'plr' VOLATILE STRICT COST 1 ROWS 1; Pretty powerful. 2) The learning curve for R was 30 days for me. (Still learning, but everything is now no longer alien.) I submitted a bug to a Professor. Not only did he fix the bug within a few hours, but he offered to personally send a new build for my platform. He also suggested a performance improvement for my code (by practically rewriting it) that resulted in code 43 times faster. The PL/R mailing list has been nothing but helpful and expedient. 3) Scalability of R functions is not too difficult to test.
- T_S_ 16y agoForeign function calls are a good thing to support. R does this well and lots of R routines already call C or Fortran libraries. Domain specific languages are good (and fun). Interacting with open source developers can be an awesome expersience. I agree. I just don't see R as a platform that can integrate tightly with other business systems. It's a user oriented tool. If there are use cases out there that disprove this. It would be interesting to hear about. Especially as we move into the era of "big data".
- thangalin 16y agoIt need not integrate tightly with other business systems. Especially as we move into an era of big data, it need only integrate well with databases. I am creating a website that allows the general public to create reports on how the climate has changed, such as: http://i.imgur.com/o8fTg.jpg http://i.imgur.com/o8fTg.jpg PHP, PostgreSQL, R, and JasperReports to analyse 273 million rows of data across 8000 weather stations spanning The Great White (soon to be Green by the looks of it) North for the last 110 years. The trend line, shown in orange, is calculated in R using a Generalized Additive Model. There is no way I was going to (or even could) write such a complex algorithm myself. When I started the project, I was using MySQL. I migrated the database to PostgreSQL specifically so that I could use R for the analysis. I migrated the database before learning R.
- T_S_ 16y agoGood stuff.