Date:         Sat, 31 Jul 2004 23:37:06 -0400
Reply-To:     Howard Schreier <Howard_Schreier@ITA.DOC.GOV>
Sender:       "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:         Howard Schreier <Howard_Schreier@ITA.DOC.GOV>
Subject:      Re: Please help: array problrm

I think having the months in a single dimension is more natural, and will
make references to the array less complicated. So I would make the first
dimension perhaps

   1:42

and elsewhere code

   retain firstmonth '01jan2002'd;

Then the month subscripts can be decoded when necessary by invoking

   intnx('month',firstmonth,month)

On Sat, 31 Jul 2004 14:32:32 -0700, Dale McLerran
<stringplayer_2@YAHOO.COM> wrote:

>--- Lou <lpogodajr292185@COMCAST.NET> wrote:
>
>> Frankly though, I'd make a more radical change than that.  You've
>> defined
>> 206 elements in your first dimension, and most of those are going to
>> be
>> unused - there is no month 200256 for instance - you appear to need
>> only 30,
>> the number of months in two and a half years.  I'd relabel those
>> months so
>> that January 2001 was simply 1, February 2001 was 2, and so on, and
>> adjust
>> my array dimension accordingly.  After all, those unused elements are
>> multiplied by the square of 132.  For every element in the first
>> dimension
>> you don't need, your array is 17,424 elements larger than it needs to
>> be.
>
>
>Yes, that was my impression too when I first looked at the problem.
>The values 200401 through 200406 are assigned to a month variable.
>I believe that these values are a combination of year and month.
>As Lou notes, there are a lot of values in the coded month declaration
>which have no utility whatsoever.  Lou suggests one way to deal
>with the problem of year/month combinations.  I would prefer not
>to perform a recode if I don't have to.  Rather, I would add a
>fourth dimension to the multidimensional array.  Let the first
>dimension be year (taking on values from 2002 through 2004),
>the second dimension be month (taking on values of 1 through 12),
>and the third and fourth dimensions be i and j (both as presently
>coded).  Thus, I would code
>
>  data _null_;
>    array t{2002:2004,1:12,0:131,0:131} _temporary_;
>    do year=LBOUND(t,1) to hbound(t,1);
>      do month=LBOUND(t,2) to hbound(t,2);
>        do i=LBOUND(t,3) to hbound(t,3);
>          do  j=LBOUND(t,4) to hbound(t,4);
>            t(year,month,i,j)=0;
>          end;
>        end;
>      end;
>    end;
>  run;
>
>
>Now, there is the problem that we want to address months only
>through the 6th month of year 2004.  We can certainly accomodate
>that by adding a LEAVE statement when year has incremented to
>2004 and month has incremented beyond 6.  Thus, we may code
>
>  data _null_;
>    array t{2002:2004,1:12,0:131,0:131} _temporary_;
>    do year=LBOUND(t,1) to hbound(t,1);
>      do month=LBOUND(t,2) to hbound(t,2);
>        if year=2004 & month>6 then leave;
>        do i=LBOUND(t,3) to hbound(t,3);
>          do  j=LBOUND(t,4) to hbound(t,4);
>            t(year,month,i,j)=0;
>          end;
>        end;
>      end;
>    end;
>  run;
>
>
>We reserve more space for the temporary array elements than
>necessary (6*132*132 values or approximately 0.8 mb).  This would
>seem to me to be of very little consequence, given today's
>computing platforms.  I would happily declare the extra space
>for the temporary array in order to code the program in the
>most natural units.
>
>Dale
>
>
>=====
>---------------------------------------
>Dale McLerran
>Fred Hutchinson Cancer Research Center
>mailto: dmclerra@fhcrc.org
>Ph:  (206) 667-2926
>Fax: (206) 667-5977
>---------------------------------------
>
>
>
>__________________________________
>Do you Yahoo!?
>Yahoo! Mail - You care about security. So do we.
>http://promotions.yahoo.com/new_mail