Why SAS programmers need to be aware of perl and R
in [SAS]
|
From: xlr82sas on 3 Mar 2010 01:55 Hi SAS-Lers, My interests in integrating perl and R with SAS is not to degrade SAS. Using the tool that is best for the task will just make you a more valuable programmer. The integration of SAS, perl and R is much greater than the sum of the individual languages. Perl which lets you do things like treat a file like a character string, you can even read or scan the file backwards(good for sequential time records). Also consider this problem, recently posed to perl. Take the numbers 123456789. Insert between each number either a + * or nothing and find the two equations whose answer is 2002" I realize this is an academic execise and does not have any real application, but it does show the power of perl. The perl program is 42 bytes long. (glob filename getdte pipe 'perl -e ''eval==2002 and print "$_ = 2002" while glob(join "{+,\ \*,}", 1..9);'''; data _null_; infile getdte; input; put _infile_; run; If you install strawberry perl, you should be able to run the SAS programe below. I ran it on unix. 28783 filename getdte pipe 28784 'perl -e ''eval==2002 and print "$_ = 2002" while glob(join "{+,\\*,}", 1..9);'''; 28785 data _null_; 28786 infile getdte; 28787 input; 28788 put _infile_; 28789 run; NOTE: The infile GETDTE is: Pipe command="perl -e 'eval==2002 and print "$_ = 2002" while glob(join "{+,\\*,}", 1..9);'" 1*2+34*56+7+89 = 2002 1*23+45*6*7+89 = 2002 As far as R is concerned it is a geat addition to SAS proper, it will allow statisticians much greater control over the formulation and executon of linear and non-linear models. It is also a great teaching tool. I good book for R beginners(like me) is A recent book by Muenchen may help some SAS users. Robert A. Muenchen. R for SAS and SPSS Users. Springer Series in Statistics and Computing. Springer, 2009. ISBN: 978-0-387-09417-5. [ bib | Discount Info | Publisher Info ] This book demonstrates which of the add-on packages are most like SAS and SPSS and compares them to R's built-in functions. It steps through over 30 programs written in all three packages, comparing and contrasting the packages' differing approaches. The programs and practice datasets are available for download. The programming world is big enough for SAS, perl and R. SOAPBOX ON; I am a little upset with SAS. I remember in the mid 90's when Larry Ellison was making it hard fro SAS to get data out of Oracle efficiently. I believe some major corporations complained to Larry that they would drop Oracle if he did not improve the SAS Oracle interface. Now the shoe is on the other foot and SAS needs to improve the interface to other languages(perl and R). Minimally a silent read/ write ODBC driver. This work should not be done by others. Instead of spending all its capital trying to take over the world(EG-SAS/SAP), like Oracles failed attempts, SAS should embrace perl and R. The R integration in IML seems rather absurd to me because I question the need for both IML and R. There is a need for R with SAS proper. Programming languages like IML have a history of eventually taking a backseat and that is just a fact of life(assembler/fortran/cobol/rpg/ basic...). SOAPBOX OFF;
From: montura on 3 Mar 2010 07:58 Sounds backwards. Seems like the people who make R and Perl need to be delivering a better interface.
From: Jonathan Goldberg on 3 Mar 2010 10:27 I agree with xlr82sas. Doing a SAS-R or SAS-Perl interface is SI's job, because they have a closed product with a proprietary data format. Reading and writing SAS data sets can only be done reliably with SAS tools, which are not redistribuable. It must be said that SAS has interfaces to both; remember the Perl data step object. The problem with building interfaces is with data type translations. I assume that's why the R interface in in IML; other parts of SAS don't have any data type that loosely corresponds to an R frame. Likewise with Perl; SAS functions cannot return arrays (and other data types). To my mind this is an arguement for moving IML to Base. So, while I think it's SI's job, that job presents problems with no obvious (at least to me) solutions.
From: montura on 3 Mar 2010 11:33 SAS can return arrays - but only with object SAS.
From: Alan Churchill on 3 Mar 2010 11:08
I think you make the case for a number of languages other than perl and R. Remember, a lot of SAS is used for ETL and not statistics so there are multiple needs. I have released an alpha dataset reader/writer on the web. Since it is alpha, I think your statement about reliably is fair until it gets more testing. So far, it seems to be holding up. Alan Alan Churchill Savian www.savian.net Office: (719) 687-5954 Cell: (719) 310-4870 -----Original Message----- From: SAS(r) Discussion [mailto:SAS-L(a)LISTSERV.UGA.EDU] On Behalf Of Jonathan Goldberg Sent: Wednesday, March 03, 2010 8:28 AM To: SAS-L(a)LISTSERV.UGA.EDU Subject: Re: Why SAS programmers need to be aware of perl and R I agree with xlr82sas. Doing a SAS-R or SAS-Perl interface is SI's job, because they have a closed product with a proprietary data format. Reading and writing SAS data sets can only be done reliably with SAS tools, which are not redistribuable. It must be said that SAS has interfaces to both; remember the Perl data step object. The problem with building interfaces is with data type translations. I assume that's why the R interface in in IML; other parts of SAS don't have any data type that loosely corresponds to an R frame. Likewise with Perl; SAS functions cannot return arrays (and other data types). To my mind this is an arguement for moving IML to Base. So, while I think it's SI's job, that job presents problems with no obvious (at least to me) solutions. |