Brian Koch
2006-Jul-27 19:53 UTC
[R] Moving from Splus to R - advice/opinions request from amanagement perspective
Hi Dave. I'll try to offer some feedback from a fellow non-stats guy working in a business setting. I've not directly transitioned from S+ to R, but I've previously hit roadblocks with SAS and SPSS that compelled me to investigate the S/R languages. I think that as you read messages on this list, you'll find that most users don't implement R as a back end to a chain of processes: Many of the community members are importing data into R via an ASCII or SQL connector (R has good base functions and/or packages for both), writing custom code for their analyses, and using the R output to [manually] compile a report or similar deliverable. So my biggest concern for the migration is the import/export. Given your evaluation of your statistics needs such that S+ might be "over-kill" - and because your organization seems to be at a crossroads for this information system, maybe take a good look at what is serving S+ its data. If it's something to the tune of SAP, MySQL, or Oracle, then that application might have enough mathematical/statistical/data management features to accomplish your objectives -- not to mention that all of these applications are extensively supported by their manufacturers (for a price, of course - hopefully competitive with Insightful and more customer-responsive). If you're planning to outsource your statistics expertise, then definitely consider this option. The biggest differences between S+ and R deal with data storage and variable scoping -- and this impacts import/export especially. Transitioning your code from S+ to R will be the most intensive when routines based on these differing features need to be re-engineered. Another consideration for management is how you might use R packages. There are a large number of them available, but as you'll see in reading this list's messages, the quality varies. I've found the R base software to be rock-solid, and I trust its accuracy. But I've been reluctant to deploy packages whose workings are beyond my expertise (i.e., a package that I couldn't debug). If you need capabilities outside of the base functions, then take a good hard look at which packages are out there (CRAN is where you find R packages - link to it from the R main site) and examine their authors and the degree stability and/or active maintenance. If the package was written by a member of the R Development Core Team, or by the author of a prominent book on R, it's more likely that package is as reliable as the base. I can attest that maintaining custom, from-scratch R analytics as a non-stats-guy is a challenging but rewarding activity. It forces you to understand the structure of your data and the interconnection of your analysis processes. So in the end, it might come down to preference. If your job is to ensure the reliability of this system and vouch for its accuracy, then perhaps R might pull you from your other responsibilities. However, if your job is to grow this system with your organization's needs, then investing in R is a great choice: When you learn R, R returns the favor and enlightens you about the data under your care. And don't forget that you can always just "try" R. It might take some bravery, but if you can take a dump/export/snapshot of some data and process it via R, you'll learn quickly whether the transition would require minor updates vs. major overhauls. And here the good folks of this list could probably help -- if you can provide a representation of your data and a description of what operations are involved (or the relevant S+ code, better yet), I think you'll find somebody with the willingness to help and the expertise to advise. There's a curious number of Fortune 500 domain names that appear in the addresses of this list's regulars... I wonder how many of them got their start by "trying" R when at a juncture similar to your own. Finally, to answer your last question about consultants: You might try guru.com to look for freelance talent. Also, if you can define your project such that someone could bid, you could post an RFP to this list (or send a general query for contract help at an hourly rate). There have also been postings to the list from professional training firms that run workshops -- perhaps they could provide a customized solution for your business. HTH, -Brian J. Koch Data Manager Decision Development Inc (A qualitative marketing research firm. Evanston, IL) -----Original Message----- From: r-help-bounces at stat.math.ethz.ch [mailto:r-help-bounces at stat.math.ethz.ch] On Behalf Of Dave Sent: Thursday, July 27, 2006 11:45 AM To: r-help at stat.math.ethz.ch Subject: [R] Moving from Splus to R - advice/opinions request from amanagement perspective Hi, I've looked through the archives and seen several posts discussing technical differences between R and S(plus). It appears to me that R can likely functionally replace Splus for my situation, but I'm more interested in looking at the risks and benefits of moving from Splus to R from a (project) management point of view. Background (a bit wordy, I'm afraid): - I'm not a stats guy, but rather a project manager responsible for an internal application that utilizes Splus as a back-end analysis engine to analyze manufacturing data at a med/large company. - I really don't know why Splus was chosen as the analysis engine for this app - that choice was made long before I inherited the project. - The developer currently in charge of the Splus code is not a stats guy either, but he is a very talented programmer that has been to one Insightful course and taught himself enough to maintain the existing code (the original authors are long gone). - While there is quite a large quantity of existing code that is used by our application, I don't believe that it is terribly complex, from an applied statistics point of view. Using Splus may be over-kill from a functionality standpoint, but we just haven't had the time to re-write in a more "appropriate" package - even if we knew what that more appropriate package might be. - With the imminent release of Splus 8, I'm feeling uncomfortable with the risk associated with remaining on Splus 2000, which we are currently using. ***Comments on this point would be appreciated.*** - The developer was able to modify the existing code to run in Splus 7. Unfortunately, the code is significantly slower than before, and Insightful claims this is due to a change to the S language (at version 6) that was out of their control (and one reason that they bought the S language rights). - We have found Insightful's telephone support to be rather unresponsive, and not very helpful, other than to recommend their consulting services. Obtaining consulting services from Insightful to improve performance has proved challenging (don't ask), and if we ever actually do receive any consulting services from them, it will no doubt be quite expensive. (if you are still with me, thank you) I see our realistic options as: A) Stick with Splus with the assumption that eventually, Insightful will help us migrate our code to the latest release, and performance will be comparable to what it is today. The advantage of this is working with a known entity, if not one we are very pleased with. In addition, if we can get the relationship to work, we can hopefully "outsource" future statistics development and support to Insightful. The disadvantage is that it is costing us quite a bit of $$$ to maintain a relationship that we are not really happy with. Incidentally, I'm not intending to bash Insightful here - it may just be that we are not a good fit for each other. B) Drop Splus for R with the assumption that migrating to R and rewriting to improve performance will be little more difficult than rewriting by ourselves in Splus. The obvious advantage is the cost savings, which is very significant. In addition, based on the archives I've read, it appears that there is a very responsive and helpful R community. The disadvantage is that we may be committing to maintaining statistical expertise in-house, whereas we were hoping to be able to outsource some or all of it (to Insightful). In addition, we will be leaving behind an entity that has a mailing address, phone number, and stock symbol for one that is represented "only" by a mailing list - I'm rather conservative and risk averse. C) Stick with Splus and either find some consulting help outside of Insightful or slog away internally. I suppose that we could even end our M&S contract with Insightful and just continue to use Splus, knowing that we will never receive any releases newer than 8.x nor any future support. (almost done) So, I'd like to hear opinions of whether you think that the benefits of moving to R outweigh the risks. Listing additional benefits and risks that I have not identified would be appreciated. I'm particularly interested in hearing from anyone that has made this same S -> R transition in a business environment. Also, does anyone have any recommendations for either Splus or R consultants, other than Insightful? I would prefer someone who is willing to work remotely, rather than anyone having to travel. Thats it. Thanks for your time, Dave __________________________________________________ [[alternative HTML version deleted]] ______________________________________________ R-help at stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
Seemingly Similar Threads
- Moving from Splus to R - advice/opinions request from a management perspective
- Splus-specific entries in pkg/DESCRIPTION files
- Splus/R typedef for C equivalent of S "integer"
- 2 Courses Near You - (1) Introduction to R/S+ programming: Microarrays Analysis and Bioconductor, (2) R/Splus Fundamentals and Programming Techniques
- Re: R or Splus