Date: Wed, 30 Jul 2003 04:01:14 -0700
Reply-To: Jonathan Siegel <jmsiegel@YAHOO.COM>
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: Jonathan Siegel <jmsiegel@YAHOO.COM>
Subject: Re: array processing
In-Reply-To: <BAY2-F111IRUlRWXopo00012895@hotmail.com>
Content-Type: text/plain; charset=us-ascii
I may have read too much into Dale's putting his
'simple' solution first. So I'll offer the opinion as
my own.
The dataset involved has 10,000 observations and 3
variables. This means that execution time is miniscule
and there isn't much in the way of efficiency to gain
from more complex methods. On the downside, there are
additional coding time and maintenance issues.
But what trumps it for me is when I think about the
specific querier who started the thread. The querier
was having difficulty doing the problem without taking
up several data steps. and said that he was not
experienced in arrays.
This should clue us tha wouldn't have been able to
maintain complex array-based code himself and would
had to go to an outside expert to deal with any
change, greatly increasing his costs. Even if generous
SAS-L folks would be willing to give him a free
solution every time he had a problem, it would still
cost him down-time explaining the problem and waiting
for the solution to arrive. And would there be
somebody there when he needed help?
All this suggests that the array-based solution would
not have been suitable to the querier's specific
needs.
My read was that Dale certainly gave a masterful
treatise on using arrays to the general SAS-L audience
of treatise-consuming SAS experts. But he also
provided a solution that might be more suitable to the
specific person who asked the question. By doing this,
Dale was being a smart consultant as well as a smart
programmer.
Jonathan Siegel
--- Paul Dorfman <paul_dorfman@hotmail.com> wrote:
> >From: Jonathan Siegel <jmsiegel@YAHOO.COM>
> >
> >As Dale points out, arrays aren't really what you
> want here. They make the
> >solution more complicated than it needs to be.
>
> Jonathan,
>
> I have read Dale's post quite carefully (which duty
> I pay to all of his
> posts, even if the subject is well above my head),
> but failed to find any
> point of this sort. Instead, I saw a rather
> masterful treatise on *using*
> arrays to achieve the objective. What gives?
>
> Kind regards,
> ===============
> Paul M. Dorfman
> Jacksonville, FL
> ===============
>
> >
> >Jonathan Siegel
> >
> >On Tue, 29 Jul 2003 11:46:03 -0700, Dale McLerran
> ><stringplayer_2@YAHOO.COM>
> >wrote:
> >
> > >A simple datastep approach that works similarly
> to Prasad's SQL
> > >solution would be as follows:
> > >
> > >data two;
> > > set one(keep=vara rename=(vara=newvar))
> > > one(keep=varb rename=(varb=newvar))
> > > one(keep=varc rename=(varc=newvar));
> > >run;
> > >
> > >
> > >An array based solution would have to load all of
> the data into
> > >memory in a two dimensional array which is
> indexed on variable
> > >and row number. When all data have been read,
> then loop back
> > >through the data by row number within variable
> index. Thus,
> > >we could write the following:
> > >
> > >data two;
> > > set one end=lastrec;
> > > array var_in {3} vara varb varc;
> > > array all_dat {3,10000} _temporary_;
> > >
> > > /* Store observed values into _n_th row of
> all_dat array */
> > > do i=1 to 3;
> > > all_dat{i,_n_}=var_in{i};
> > > end;
> > >
> > > /* Once we have read all the data, then loop
> over rows */
> > > /* within variable indexes and write the stored
> value. */
> > > if lastrec then do;
> > > do i=1 to 3;
> > > do j=1 to _n_;
> > > newvar = all_dat{i,j};
> > > output;
> > > end;
> > > end;
> > > end;
> > > keep newvar;
> > >run;
> > >
> > >
> > >Hope these help,
> > >
> > >Dale
>
>
_________________________________________________________________
> Add photos to your messages with MSN 8. Get 2 months
> FREE*.
> http://join.msn.com/?page=features/featuredemail
>
| 
