Unstructured data will always be with us since people communicate in an
unstructured way. Will the unstructured section be held within a structured
framework? Sure, I can see that.
From: Vincent Granville [mailto:email@example.com]
Sent: Monday, September 01, 2008 11:19 AM
To: Alan Churchill; SAS-L@LISTSERV.UGA.EDU
Subject: RE: Calling R, C, C++, C#, Java, Python, Perl, etc. from a SAS
I found it much easier to process un-structured data in Perl then
feed the cleaned, summarized data to SAS. You get the best of both
languages when you proceed as suggested, and it takes considerably
less time to finish the project.
Now, I know a few very good SAS programmers who know all the
substleties of string parsing in SAS and can do with SAS what I do
with Perl, as easily. But I'm not one of them.
PS: one of my colleagues believe that un-structured data is a thing
of the past. In a few years, all data (even messages posted on
usenet) will be structured.
At 07:28 PM 8/25/2008, Alan Churchill wrote:
>Let's look at the process.
>SAS produces a dataset after a lot of processing. You don't need a 3rd
>calling a 3rd to do something.
>Read a SAS dataset directly using the FREE SAS OleDb driver. Once it is in
>memory, manipulate to your heart's content and then write it back out to
>source you need it to go in.
>Minimal steps reduce the surface area.
>From: SAS(r) Discussion [mailto:SAS-L@LISTSERV.UGA.EDU] On Behalf Of
>Sent: Monday, August 25, 2008 8:03 PM
>Subject: Calling R, C, C++, C#, Java, Python, Perl, etc. from a SAS program
>What about a Perl script calling SAS, R, C++, C# etc. rather than SAS
>calling these languages? Wouldn't it be easier? What are the pluses /
>I'm used to write Perl scripts to pre-process messy data (text mining) and
>produce summary tables, then feed the clean summary tables to SAS. What do
>SAS engineers think about this strategy?
>Anybody has thoughts on this? Feel free to reply on
Vincent Granville, Ph.D.
Founder and Principal