Date: Mon, 4 Jun 2001 10:06:54 -0700
Reply-To: Dale McLerran <dmclerra@MY-DEJA.COM>
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: Dale McLerran <dmclerra@MY-DEJA.COM>
Subject: Re: _temporary_ arrays vs "regular" arrays
You do bring up a host of issues here, certainly more than can be
addressed at any one time. Paul Dorfman will come down on you for
suggesting that the SAS datastep is not a full-featured programming
language. To a certain degree, he is correct in that. There is a
lot of unused potential in the simple SAS datastep. Temporary arrays
holding millions of observations can be employed. Since temporary
arrays are held only in memory, manipulations of the data can be
quite fast. Also, Paul has shown us how to do various types of
operations on the data held in temporary arrays, including sorting
of data, setting up hash tables, etc. These do bring quite a bit of
power to the SAS datastep.
At the same time, there are certain limitations of the SAS datastep.
For instance, in my work as a statistician I have need to invert
matrices. Could this be programmed in a datastep? Yes, I believe
that it could be done. However, is it worth my while to attempt to
do so? The answer is a resounding NO! SAS does have a "real
programming language" with the IML product. (Shh, don't let Paul
hear me say that.) Another poster asked within the past few days
whether there was a way to re-initialize an entire array, apart from
using a do loop to set the array elements to the requisite value.
This may (and should) be developed in the SAS datastep in the future.
However, it is already available in IML. IML brings additional
programming functionality that is simply not intended for the
In some form or another, SAS probably has the tools that you need.
Of course, IML is another product requiring licensing. And IML has
certain limitations. It does not perform arithmetic on complex
numbers as some languages do. There are a lot of (rarely used, in my
consideration) vector and matrix operations which are not programmed
in IML. IML brings to the table the majority of "real programming
language" requirements. But no language is best for everything.
And that is certainly true of IML. I might wish that there were
hooks from IML into other procedures, so that I didn't have to leave
IML to run that mixed model regression. Other languages which are
not segmented into DATA and PROC steps do not impose some of the
restrictions which are a bona-fide feature of SAS. I am just trying
here to give a little perspective to what you already know, that there
is never a single solution which performs all jobs optimally. But
SAS has done a great job are presenting solutions for the most common
problems which you might encounter. That includes a very powerful
datastep. And if you can't get the job done in a datastep, then you
have another tool available (subject to license) which will almost
surely do the required job.
>Date: Sun, 3 Jun 2001 00:11:53 GMT
>Reply-To: RICH0850 <rich0850@AOL.COM>
>From: RICH0850 <rich0850@AOL.COM>
>I recently received excellent solutions to my array sort problem from this list
>(thanks Jay, Puddin', and Paul) which makes me think we should initiate a
>descussion of different sort methods (bubble, insertion, shell, etc.). We'll
>do this another time.
>SAS documentation indicates that _temporary_ arrays may result in performance
>improvements over "regular" arrays. In my case, I only need arrays for
>calculations. They are thrown away after I'm done.
>How much am I saving here? Do _temporary_ arrays obviate concerns about the
>number of variables in a dataset? I know I can't apply many of the SAS
>built-in functions to _temp_ arrays, but all I want is the array functionality
>provided by even a language as old as FORTRAN.
>What if I needed to process an array of 60,000 elements? Does a _temp_ array
>allow me to do this?
>I know I'm asking SAS to be a real computer language. I'm just worn out with
>SAS's built-in limitations (fully knowing that these limitations allow for
>flexibility and power).
>I've brought-up several issues here... forgive me.
Fred Hutchinson Cancer Research Center
Ph: (206) 667-2926
Fax: (206) 667-5977
--== Sent via Deja.com ==--