Why SAS programmers need to be aware of perl and R
in [SAS]
|
From: xlr82sas on 3 Mar 2010 12:40 On Mar 3, 8:08 am, alan.church...(a)SAVIAN.NET (Alan Churchill) wrote: > 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 > Savianwww.savian.net > Office: (719) 687-5954 > Cell: (719) 310-4870 > > > > -----Original Message----- > From: SAS(r) Discussion [mailto:SA...(a)LISTSERV.UGA.EDU] On Behalf Of > > Jonathan Goldberg > Sent: Wednesday, March 03, 2010 8:28 AM > To: SA...(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.- Hide quoted text - > > - Show quoted text - Hi Alan, The writer is a major accomplishment. Thanks. Currently I know of no 'suitable' method to get variables with character lengths longer than 200 bytes and loss less numerics out of R other than your writer. Your tool fills this canyon, it is not a gap. The ODBC server is unacceptable for me. I think the ultimate interface will be something like a Java obj, where SAS in memory arrays can be shared with perl and R. I think I am almost there but my interface will just be a proof of concept, my real hope is that SAS will provide an IML like interface in SAS proper. My interface will be a toy until SAS gets the message. I was toying with the idea of asking you and Chris to hold back on the writer. This way your tools can get SAS data into R reliably but programmers can't get R dataframes back to SAS. Maybe SAS would start listening if it is a one way street away from SAS. Perhaps my interfaces can help users learn perl and R from SAS. I do allow the user to mix SCL, SAS, perl and R code and compare results. Regards Regards
From: xlr82sas on 3 Mar 2010 12:53 On Mar 3, 9:40 am, xlr82sas <xlr82...(a)aol.com> wrote: > On Mar 3, 8:08 am, alan.church...(a)SAVIAN.NET (Alan Churchill) wrote: > > > > > > > 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 > > Savianwww.savian.net > > Office: (719) 687-5954 > > Cell: (719) 310-4870 > > > -----Original Message----- > > From: SAS(r) Discussion [mailto:SA...(a)LISTSERV.UGA.EDU] On Behalf Of > > > Jonathan Goldberg > > Sent: Wednesday, March 03, 2010 8:28 AM > > To: SA...(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.- Hide quoted text - > > > - Show quoted text - > > Hi Alan, > > The writer is a major accomplishment. Thanks. > > Currently I know of no 'suitable' method to get variables with > character lengths longer than 200 bytes and loss less numerics out of > R other than your writer. Your tool fills this canyon, it is not a > gap. The ODBC server is unacceptable for me. > > I think the ultimate interface will be something like a Java obj, > where SAS in memory arrays can be shared with perl and R. I think I am > almost there but my interface will just be a proof of concept, my real > hope is that SAS will provide an IML like interface in SAS proper. My > interface will be a toy until SAS gets the message. > > I was toying with the idea of asking you and Chris to hold back on > the writer. This way your tools can get SAS data into R reliably but > programmers can't get R dataframes back to SAS. Maybe SAS would start > listening if it is a one way street away from SAS. > > Perhaps my interfaces can help users learn perl and R from SAS. I > do allow the user to mix SCL, SAS, perl and R code and compare > results. > > Regards > > Regards- Hide quoted text - > > - Show quoted text - By the Way, I may have a copy of the 'letter to Oracle' from SAS complaining about the impact Oracle's inefficient interface was having on customers. I remember reading it. I hope this is a ghost memory, does any one else out there remember the 'letter' Regards
From: Dale McLerran on 3 Mar 2010 13:20 --- On Wed, 3/3/10, Jonathan Goldberg <jgoldberg(a)BIOMEDSYS.COM> wrote: > From: Jonathan Goldberg <jgoldberg(a)BIOMEDSYS.COM> > Subject: Re: Why SAS programmers need to be aware of perl and R > To: SAS-L(a)LISTSERV.UGA.EDU > Date: Wednesday, March 3, 2010, 7:27 AM > 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). Having used the IML Studio product to run R code directly from SAS, I have to take exception with the statement that SAS does not have any data type that loosely corresponds to an R data frame. The R data frame is really quite like a SAS data set. The R data frame is a rectangular structure with columns (variables) and rows (observations). Each column has n rows and each column is of type character, numeric, logical, or complex. SAS does not have logical or complex data types. However, logical data types are translated as binary values (FALSE=0, TRUE=1). Complex data types are not translated, so they are a problem for SAS. But most data frames are not going to have columns which are complex numbers. Thus, for the most part, an R data frame and a SAS data set can be considered as equivalent data types. In fact, when one runs the IML Studio function ExportDataSetToR, an R data frame is created. SAS regards the R data frame as a structure which is equivalent to a SAS data set. Thus, the argument presented by Jonathan is not a reason for a lack of an interface to R from Base SAS. > > To my mind this is an arguement for moving IML to Base. Now, I would really like to see that! However, I am not sure how that would be implemented. But I have long maintained that SAS will lose ground to other languages which fully integrate matrix processing with other components of the language. > > So, while I think it's SI's job, that job presents problems with no > obvious (at least to me) solutions. > I do believe that SI could construct an interface to R from Base SAS if they really wanted to. R is not going away, but is siphoning users away from SAS. SAS will do best in the long run to fully recognize R and make available to users the ability to conveniently access R. To most users, that means being able to invoke R from Base SAS. I know that it could be done if SI put their minds to it! --------------------------------------- Dale McLerran Fred Hutchinson Cancer Research Center mailto: dmclerra(a)NO_SPAMfhcrc.org Ph: (206) 667-2926 Fax: (206) 667-5977 ---------------------------------------
From: Alan Churchill on 3 Mar 2010 13:53 Just so you know, Chris and I do not share any code base whatsoever. I do my thing, he does his thing and we are separated by an ocean to boot. Hence, this is not a collaborative effort. No on holding back. I will not delay to aid in a fight I don't care and park my 18 months of work (mostly solo) on a shelf. 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 xlr82sas Sent: Wednesday, March 03, 2010 10:41 AM To: SAS-L(a)LISTSERV.UGA.EDU Subject: Re: Why SAS programmers need to be aware of perl and R On Mar 3, 8:08 am, alan.church...(a)SAVIAN.NET (Alan Churchill) wrote: > 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 > Savianwww.savian.net > Office: (719) 687-5954 > Cell: (719) 310-4870 > > > > -----Original Message----- > From: SAS(r) Discussion [mailto:SA...(a)LISTSERV.UGA.EDU] On Behalf Of > > Jonathan Goldberg > Sent: Wednesday, March 03, 2010 8:28 AM > To: SA...(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.- Hide quoted text - > > - Show quoted text - Hi Alan, The writer is a major accomplishment. Thanks. Currently I know of no 'suitable' method to get variables with character lengths longer than 200 bytes and loss less numerics out of R other than your writer. Your tool fills this canyon, it is not a gap. The ODBC server is unacceptable for me. I think the ultimate interface will be something like a Java obj, where SAS in memory arrays can be shared with perl and R. I think I am almost there but my interface will just be a proof of concept, my real hope is that SAS will provide an IML like interface in SAS proper. My interface will be a toy until SAS gets the message. I was toying with the idea of asking you and Chris to hold back on the writer. This way your tools can get SAS data into R reliably but programmers can't get R dataframes back to SAS. Maybe SAS would start listening if it is a one way street away from SAS. Perhaps my interfaces can help users learn perl and R from SAS. I do allow the user to mix SCL, SAS, perl and R code and compare results. Regards Regards
From: "F. J. Kelley" on 3 Mar 2010 13:50
I wondered if any other old timer would remember this. Proc Matrix was removed as of V6, but had been a staple of SAS in the years before. With Matrix you could write stat procs which did not exist in SAS/Stat (at the time). wrt connecting to other stat packages, there used to be a "SASBMDP" which would allow you to call BMDP from SAS. For those who remember it, BMDP had some great (for the time) procs, but horrible data manipulation capabilities. Given that it was very Fortran-ish, character data was a real pain. --Joe ---- Original message ---- >Date: Wed, 3 Mar 2010 13:31:48 -0500 >From: "SAS(r) Discussion" <SAS-L(a)LISTSERV.UGA.EDU> (on behalf of Mike Rhoads <RHOADSM1(a)WESTAT.COM>) >Subject: Re: [SAS-L] Why SAS programmers need to be aware of perl and R >To: SAS-L(a)LISTSERV.UGA.EDU > >" To my mind this is an argument for moving IML to Base." > >Funny someone should mention that. SAS/IML is really an evolved and improved version of PROC MATRIX, which other old-timers will remember used to be part of the "base" SAS product. (Of course, there only was one SAS product way back then.) As it happens, PROC MATRIX was actually the key capability that jump-started the use of SAS at Westat ... and the rest is history, as they say. > >I suspect that in this case, what goes around probably will NOT come back around again. ;-) > > >Mike Rhoads >RhoadsM1(a)Westat.com > > >-----Original Message----- >From: SAS(r) Discussion [mailto:SAS-L(a)LISTSERV.UGA.EDU] On Behalf Of Jonathan Goldberg >Sent: Wednesday, March 03, 2010 10: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. |