LISTSERV at the University of Georgia
Menubar Imagemap
Home Browse Manage Request Manuals Register
Previous messageNext messagePrevious in topicNext in topicPrevious by same authorNext by same authorPrevious page (January 2002, week 3)Back to main SAS-L pageJoin or leave SAS-L (or change settings)ReplyPost a new messageSearchProportional fontNon-proportional font
Date:         Wed, 16 Jan 2002 10:37:15 -0500
Reply-To:     Ian Whitlock <WHITLOI1@WESTAT.COM>
Sender:       "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:         Ian Whitlock <WHITLOI1@WESTAT.COM>
Subject:      simple data transformation question
Comments: To: "biostat2001@HOTMAIL.COM" <biostat2001@HOTMAIL.COM>
Comments: cc: "Paul.Dorfman@BCBSFL.COM" <Paul.Dorfman@BCBSFL.COM>
Content-Type: text/plain; charset="iso-8859-1"

Paul,

Two points.

One I think you left some distinguished gentleman such as Sigurd H. and many others that at one time or another expressed the same view.

Two, you are quick to point out the efficiencies of peeking and poking without pointing to the maintenance problems one is open to, so I will take a peek at them. Let's consider various simple modifications of your program.

data a ( drop = y ) ; ***retain pt lc lp rc rp ; ***length lp 3 ; input pt rc y lc rp lp ; cards; 1 1 -9 2 3 4 1 1 -9 2 3 4 2 5 -9 6 7 8 2 5 -9 6 7 8 3 9 -9 0 1 2 3 9 -9 0 1 2 3 9 -9 0 1 2 4 3 -9 4 5 6 4 3 -9 4 5 6 run ;

data b (drop = rc lc rp lp ) ; array all rc0 lc0 rp0 lp0 rc1 lc1 rp1 lp1 rc3 lc3 rp3 lp3 ; ***drop y ; ***retain rc0 ; do _n_ = 0 by 1 until (last.pt) ; set a /*( drop = y )*/ ; by pt ; call poke(peekc(addr(rc),32), addr(rc0)+_n_*32, 32) ; end ; run ;

This code works (as tested under Windows 98/SAS 8.2). However, if one makes any of the SAS-trivial changes suggested by the commented code (with one exception) one has a disaster. (Note: The DROP comments in the second step assume Y has not been dropped in the first step.)

One should conclude that this sort of programming on this scale (two small steps) is safe enough *if* one knows all the side effects caused by each line of code *and* one is willing to drop or very carefully consider many lines that most SAS programmers would consider as trivial changes rarely disturbing good stable SAS code.

If you think on a more realistic scale where step one may be 10 steps removed from step two or even run is a separate program, and any step that copies A may introduce problems in step 2, then it seems this sort of programming must be reserved for study programs and very tight closely coupled steps.

Paul, I do not doubt that I am not telling you anything new, but I suspect many on this list might not be in the same position. The very fact that Dawn asked the question suggests that you should at least warn her that your suggestion was not meant for her, but rather to poke at others.

IanWhitlock@westat.com

-----Original Message----- From: Dorfman, Paul [mailto:Paul.Dorfman@BCBSFL.COM] Sent: Wednesday, January 09, 2002 1:51 PM To: SAS-L@LISTSERV.UGA.EDU Subject: Re: simple data transformation question

Dawn,

I concur with Bob V. that you should have a very good reason to take data in the form well lending themselves to standard processing methods and turn them into a form where the data (VISNUM) is mixed with the metadata (RC, LC, ...) in the file descriptor. Ian W. and Howard S. have argued this point convincingly, eloquently, and repeatedly. (One reason I have found that some people want to look at data this way is the habit of looking at text files layed out using Cobol OCCURS).

The stuff that follows might be the most efficient approach when one has many more variables to stretch than 4. Then the en masse move to a precomputed address is more speedy than filling arrays up one item at a time. Other than that, to folks so inclined it can be just a fun stuff to figure out how it goes about its SAS business. Note how aligning the bottom of the W-loop with the bottom of the implied loop facilitates automatic array clean-up before each BY-group commences.

data a ; input pt rc lc rp lp ; cards; 1 1 2 3 4 1 1 2 3 4 2 5 6 7 8 2 5 6 7 8 3 9 0 1 2 3 9 0 1 2 3 9 0 1 2 4 3 4 5 6 4 3 4 5 6 run ;

data b (drop = rc lc rp lp) ; array all rc0 lc0 rp0 lp0 rc1 lc1 rp1 lp1 rc3 lc3 rp3 lp3 ; do _n_ = 0 by 1 until (last.pt) ; set a ; by pt ; call poke(peekc(addr(rc),32), addr(rc0)+_n_*32, 32) ; end ; run ;

Kind regards, ====================== Paul M. Dorfman Jacksonville, FL ======================

> -----Original Message----- > From: Dawn [mailto:biostat2001@HOTMAIL.COM] > Sent: Wednesday, January 09, 2002 9:19 AM > To: SAS-L@LISTSERV.UGA.EDU > Subject: simple data transformation question > > > Greetings: > > What's the best(most efficient) way to transform the following data? > > PT VISNUM RC LC RP LP > 1 0 7 8 9 9 > 1 1 9 3 2 1 > 2 0 6 7 9 8 > 2 1 8 3 3 2 > > to: > > PT RC0 LC0 RP0 LP0 RC1 LC1 RP1 LP1 > 1 7 8 9 9 9 3 2 1 > 2 6 7 9 8 8 3 3 2 > > I performed a PROC TRANSPOSE for RC, LC, RP, LP separately, > then merge the > transpose output back by PT. But I think there must be a more > efficient way > to do this. > > Any suggestions? > > Dawn

Blue Cross Blue Shield of Florida, Inc., and its subsidiary and affiliate companies are not responsible for errors or omissions in this e-mail message. Any personal comments made in this e-mail do not reflect the views of Blue Cross Blue Shield of Florida, Inc.


Back to: Top of message | Previous page | Main SAS-L page