Why SAS programmers need to be aware of perl and R
in [SAS]
|
From: Jonathan Goldberg on 4 Mar 2010 12:00 Yes, I remember wondering at the time what they were thinking. Proc FSCalc ran on TSO of CMS. Can you imagine inflicting either of those on finance spreadsheet jockey types? On Thu, 4 Mar 2010 08:09:46 -0500, Mike Rhoads <RHOADSM1(a)WESTAT.COM> wrote: >Alan, > >You are absolutely correct! > >Take a look at http://www.uc.edu/sashtml/ets/chap1/sect30.htm, for a blast from the past. > >Or http://www.amazon.com/gp/offer-listing/1555444555/ref=dp_olp_0? ie=UTF8&condition=all. > > >Mike Rhoads >RhoadsM1(a)Westat.com > > >-----Original Message----- >From: Alan Churchill [mailto:alan.churchill(a)savian.net] >Sent: Wednesday, March 03, 2010 7:10 PM >To: Mike Rhoads; SAS-L(a)LISTSERV.UGA.EDU >Subject: RE: Why SAS programmers need to be aware of perl and R > >I thought it was part of SAS/Calc, a separate product. > >That takes me all the way back to the mainframe... > >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 Mike Rhoads >Sent: Wednesday, March 03, 2010 3:50 PM >To: SAS-L(a)LISTSERV.UGA.EDU >Subject: Re: Why SAS programmers need to be aware of perl and R > >Actually, I believe it was PROC FSCALC. I can't remember whether it was part of Base SAS or SAS/FSP (as the name would suggest). > >There are still a couple of references to it buried on sas.com. ;-) > > >Mike Rhoads >RhoadsM1(a)Westat.com > > > >-----Original Message----- >From: SAS(r) Discussion [mailto:SAS-L(a)LISTSERV.UGA.EDU] On Behalf Of John Burton >Sent: Wednesday, March 03, 2010 3:42 PM >To: SAS-L(a)LISTSERV.UGA.EDU >Subject: Re: Why SAS programmers need to be aware of perl and R > >Yep, that's what I thought it was, > >but didn't want to say so, be incorrect and appear the fool. > >I tried to use it to develop a project for a client (the company comptroller's secretary), but she didn't like it. >So, I had to simulate another spreadsheet using Data Step Programming and SAS/FSE. > > >Best Cheers, >Ray Burton >Richmond VA >AnalyticBridge, inCircle, Linked-In, MedZilla, SAS/L, IT-Toolbox http://www.analyticbridge.com/profile/rayburton/ >http://www.linkedin.com/in/johnrayburton/ >http://it.toolbox.com/people/ray_burton/?pv=1/ > >On Wed, Mar 3, 2010 at 3:36 PM, F. J. Kelley <jkelley(a)uga.edu> wrote: >> proc CALC? >> >> I don't believe I ever used it. >> >> ---- Original message ---- >>>Date: Wed, 3 Mar 2010 15:32:16 -0500 >>>From: "SAS(r) Discussion" <SAS-L(a)LISTSERV.UGA.EDU> (on behalf of John >>>Burton <jrburtonsaspro(a)GMAIL.COM>) >>>Subject: Re: [SAS-L] Why SAS programmers need to be aware of perl and >>>R >>>To: SAS-L(a)LISTSERV.UGA.EDU >>> >>>On Wed, Mar 3, 2010 at 1:50 PM, F. J. Kelley <jkelley(a)uga.edu> wrote: >>>> 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). >>>> >>> >>>I wonder if the old-timers and the spreadsheet proc that was in Base >>>SAS back in the 80s? I don't remember the name of the proc, but that >>>it soon disappeared as some PC shreadsheet was the dominent software >>>at the time and that has now been replaced by MS/Excell. >>> >>>-- >>>Best Cheers, >>>Ray Burton
From: Dale McLerran on 4 Mar 2010 14:01 --- On Thu, 3/4/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: Thursday, March 4, 2010, 8:55 AM > Three little points: > > 1) > Dale: > You're not really taking exception; I wrote: > >>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. > In other words, I agree that an R frame and a SAS data set are > very similar; it's just that only IML has any facilities for > manipulating SAS data sets as entities. (Unless perhaps you > count the table processing language). > Jonathan, Can you elaborate on the facilities in IML for manipulating data sets as entities. I'm afraid that I don't understand your argument. Also, why must a SAS data set be mapped into an R data frame as an entity? Dale --------------------------------------- Dale McLerran Fred Hutchinson Cancer Research Center mailto: dmclerra(a)NO_SPAMfhcrc.org Ph: (206) 667-2926 Fax: (206) 667-5977 ---------------------------------------
From: xlr82sas on 4 Mar 2010 17:21 On Mar 4, 11:01 am, stringplaye...(a)YAHOO.COM (Dale McLerran) wrote: > --- On Thu, 3/4/10, Jonathan Goldberg <jgoldb...(a)BIOMEDSYS.COM> wrote: > > > > > > > From: Jonathan Goldberg <jgoldb...(a)BIOMEDSYS.COM> > > Subject: Re: Why SAS programmers need to be aware of perl and R > > To: SA...(a)LISTSERV.UGA.EDU > > Date: Thursday, March 4, 2010, 8:55 AM > > Three little points: > > > 1) > > Dale: > > You're not really taking exception; I wrote: > > >>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. > > In other words, I agree that an R frame and a SAS data set are > > very similar; it's just that only IML has any facilities for > > manipulating SAS data sets as entities. (Unless perhaps you > > count the table processing language). > > Jonathan, > > Can you elaborate on the facilities in IML for manipulating data > sets as entities. I'm afraid that I don't understand your > argument. > > Also, why must a SAS data set be mapped into an R data frame as > an entity? > > Dale > > --------------------------------------- > Dale McLerran > Fred Hutchinson Cancer Research Center > mailto: dmclerra(a)NO_SPAMfhcrc.org > Ph: (206) 667-2926 > Fax: (206) 667-5977 > ---------------------------------------- Hide quoted text - > > - Show quoted text - Hi Sas-Lers, Proc matrix was part of base SAS and had a couple of nice properties on big IBM mainframes. 1. It had limited but useful 128bit numeric capabilites(way ahead of its time) 2. It used IBM's separate 'hardware vector engine' for fast parallel vector operations (way ahead of its time) SOAPBOX ON: I made heavy use of 'proc matrix' and when SAS decided to rip it out of base and charge very high fees for large two sided 8 way mainframes, my management was not pleased. SAS did provide a translator from Matrix to IML. Here is what scares me at SAS: 1. It looks like Enterprise Guide is the window to future SAS and SAS_SAP. Also it looks like EG is somehow in bed with Microsoft's proprietary .NET. Suppose Microsoft comes out with a Starship Enterprise Version of .NET and decides to charge $500,000 dollars for Startship Enterprise .NET. SAS is also prety good at playing this game. 2. I worry about EG as a poison pill for programmers and companies. Suppose programmers get sucked into the givaway EG. SAS throws in IOM, metadata servers, stored processes, data architechure tools .. low cost at first. Then comes the 'proc matrix' hammer and programmers and companies have to pony up with massive spending increases or massive reprogramming to move away from SAS-SAP. For instance if the once free components of EG, like proc matrix, are now enterprise versions at extra cost. I think EG should reflect the future costs now. It should be priced at least 2x Windows Base SAS + SAS-Connect. Companies need to take a close look at future IT costs and SAS's revenue strategy with respect to EG. Just look at the costs asssociated with SAP. I also don't like it when SAS gives away 'ODS GRAHICS' and then charges for it later. I know this in not strickly bait and switch, but it smells. I also find it very hypocritical for SAS to complain openly about an inefficient interface to Oracle, when SAS does not even have a silient ODBC product. SOAPBOX OFF:
From: "Keintz, H. Mark" on 5 Mar 2010 10:52 XLR82SAS said: > -----Original Message----- > From: SAS(r) Discussion [mailto:SAS-L(a)LISTSERV.UGA.EDU] On Behalf Of > xlr82sas > Sent: Thursday, March 04, 2010 5:22 PM > To: SAS-L(a)LISTSERV.UGA.EDU > Subject: Re: Why SAS programmers need to be aware of perl and R > > On Mar 4, 11:01 am, stringplaye...(a)YAHOO.COM (Dale McLerran) wrote: > > --- On Thu, 3/4/10, Jonathan Goldberg <jgoldb...(a)BIOMEDSYS.COM> > wrote: > > > > > > > > > > > > > From: Jonathan Goldberg <jgoldb...(a)BIOMEDSYS.COM> > > > Subject: Re: Why SAS programmers need to be aware of perl and R > > > To: SA...(a)LISTSERV.UGA.EDU > > > Date: Thursday, March 4, 2010, 8:55 AM > > > Three little points: > > > > > 1) > > > Dale: > > > You're not really taking exception; I wrote: > > > >>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. > > > In other words, I agree that an R frame and a SAS data set are > > > very similar; it's just that only IML has any facilities for > > > manipulating SAS data sets as entities. (Unless perhaps you > > > count the table processing language). > > > > Jonathan, > > > > Can you elaborate on the facilities in IML for manipulating data > > sets as entities. I'm afraid that I don't understand your > > argument. > > > > Also, why must a SAS data set be mapped into an R data frame as > > an entity? > > > > Dale > > > > --------------------------------------- > > Dale McLerran > > Fred Hutchinson Cancer Research Center > > mailto: dmclerra(a)NO_SPAMfhcrc.org > > Ph: (206) 667-2926 > > Fax: (206) 667-5977 > > ---------------------------------------- Hide quoted text - > > > > - Show quoted text - > > Hi Sas-Lers, > > Proc matrix was part of base SAS and had a couple of nice properties > on big IBM mainframes. > > 1. It had limited but useful 128bit numeric capabilites(way > ahead of its time) > 2. It used IBM's separate 'hardware vector engine' for fast > parallel vector operations (way ahead of its time) > > SOAPBOX ON: > > I made heavy use of 'proc matrix' and when SAS decided to rip it out > of base and charge very high fees for large two sided 8 way > mainframes, my management was not pleased. > > SAS did provide a translator from Matrix to IML. > > Here is what scares me at SAS: > > 1. It looks like Enterprise Guide is the window to future SAS > and SAS_SAP. Also it looks like EG is somehow in bed with Microsoft's > proprietary .NET. Suppose Microsoft comes out with a Starship > Enterprise Version of .NET and decides to charge $500,000 dollars for > Startship Enterprise .NET. SAS is also prety good at playing this > game. > > 2. I worry about EG as a poison pill for programmers and > companies. Suppose programmers get sucked into the givaway EG. SAS > throws in IOM, metadata servers, stored processes, data architechure > tools .. low cost at first. Then comes the 'proc matrix' hammer and > programmers and companies have to pony up with massive spending > increases or massive reprogramming to move away from SAS-SAP. For > instance if the once free components of EG, like proc matrix, are now > enterprise versions at extra cost. > > I think EG should reflect the future costs now. It should be > priced at least 2x Windows Base SAS + SAS-Connect. Companies need to > take a close look at future IT costs and SAS's revenue strategy with > respect to EG. Just look at the costs asssociated with SAP. I also > don't like it when SAS gives away 'ODS GRAHICS' and then charges for > it later. I know this in not strickly bait and switch, but it smells. > > I also find it very hypocritical for SAS to complain openly about > an inefficient interface to Oracle, when SAS does not even have a > silient ODBC product. > > SOAPBOX OFF: XLR8: Of course, the pricing practices that you are criticising are shared by many, if not most, marketers of high cost products. SAS has successfully used an analogous technique by charging schools about $100 for what private enterprises pay (in at least one instance) $15,000. It's just a smart way of creating price-inelastic demand for a product. Wouldn't most of us think SAS stupid to charge the commerical price to institutions where many future SAS users are generated? To request that EG be priced to reflect future costs now would be very unpersuasive for any entity trying to introduce a significant new feature/product. This is how companies take risks. In fact, you could argue that companies offering high-end products are virtually forced to take risks via (1) invest a lot in development, (2) create low introductory prices, and (3) hope to recover the investment when the product gets priced closer to true costs. If users balk, then the research and development investment failed (and such an event would be an opportunity for IBM/SPSS to develop and distribute a bridge to their putatviely competing prodcut). And I don't think the question is whether "programmers" are sucked into using free EG. This product is targetted instead at sas USERS. As a progammer, I doubt that EG will forseeably provide the flexibility that I need from SAS, but I can see where it might become desirable, and even essential, for many of our users. These are people (and future decision-makers) who only occasionally need SAS, and who want fewer barriers to defining and implementing a data processing and analysis task. Many of these are "one-off" tasks, where program efficiency takes second place to programmming efficiency. In short, I think it's hard to criticize the thinking behind the strategic product development and pricing strategy that SAS EG represents, even though it doesn't help me one bit. Regards, Mark
From: oloolo on 5 Mar 2010 14:31
I hope SAS could continuously improving its Java.Obj interface to JAVA. I think this is the way to go. Nowadays, Java is powerful enough for some serious numeric crunching work and there are plenty of open source Java packages for statistical and data mining algorithms which I want to leverage. On Wed, 3 Mar 2010 10:27:44 -0500, Jonathan Goldberg <jgoldberg(a)BIOMEDSYS.COM> wrote: >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. |