home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / bit / listserv / sasl / 3398 < prev    next >
Encoding:
Text File  |  1992-07-22  |  2.6 KB  |  67 lines
  1. Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
  2. Path: sparky!uunet!gatech!paladin.american.edu!auvm!NIHCU.BITNET!HIS
  3. Message-ID: <SAS-L%92072216442546@UGA.CC.UGA.EDU>
  4. Newsgroups: bit.listserv.sas-l
  5. Date:         Wed, 22 Jul 1992 16:44:29 EDT
  6. Reply-To:     Howard Schreier <HIS@NIHCU.BITNET>
  7. Sender:       "SAS(r) Discussion" <SAS-L@UGA.BITNET>
  8. From:         Howard Schreier <HIS@NIHCU.BITNET>
  9. Subject: RE: multiple identical id vars problem
  10. Lines: 55
  11.  
  12. CONTENT:   Comment on "multiple identical id vars problem"
  13. SUMMARY:   Re-shaping data set with series of PROC TRANSPOSEs
  14. REL/PLTF:  6.04/ PC DOS
  15.  
  16. From Kernon Gibes (gibes@swirl.monsanto.com):
  17.  
  18. >  Ed Silverman wrote that he wanted to re-organize:
  19. >
  20. > ID           CODE  TERM  DATE
  21. >
  22. > 002162706    292  901   900309
  23. > 002162706    292  901   900403
  24. > 002254401    299  891   890201
  25. > 002254401    299  901   900303
  26. > 002254401    276  901   900405
  27. >
  28. > into (one observation per ID, multiple variables):
  29. >
  30. > ID         CODE TERM DATE  CODE2 TERM2 DATE2  CODE3 TERM3 DATE3
  31. >
  32. > 002162706  292  901 900309 299*  901   900403
  33. > 002254401  299  891 890201 299   901   900303  299** 901  900405
  34. >
  35. >  (I'm assuming that 299* should be 292 and 299** should be 276??????)
  36. >
  37. >  Since this is 6.04 he can't use SQL [ha ha ;-) ].
  38.  
  39. Actually, the target shape of the data set (repeating groups of
  40. parallel variables) is alien to the relational approach to data
  41. management and therefore SQL does not lend itself. Note that SQL does
  42. not have arrays and that repetitive processing is something that
  43. happens over like *rows*, not columns.
  44.  
  45. >  This could be done easily enough in a data step with arrays and LAST.
  46. >  processing, but since it's not clear that we know in advance the
  47. >  maximum number of unique ID values, I've given one approach using PROC
  48. >  TRANSPOSEs below. This doesn't give the desired order of variables and
  49. >  missing values might present problems, but I'll leave the data step
  50. >  approach to someone else!
  51.  
  52. Maybe there is a role for SQL! Under 6.06+, I think a fairly simple
  53. query *could* determine the maximum number of unique ID values and
  54. stick it into a macro variable, so that a DATA step approach could be
  55. generalized. However, the series of TRANSPOSEs is the approach which
  56. thought of first when I saw this problem, and is what I would use
  57. under any version.
  58.  
  59. [Kernon's code deleted]
  60.  
  61. /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
  62. \   Howard Schreier, U.S. Dept. of Commerce, Washington    /
  63. /                     MVS 5.18 & 6.07                      \
  64. \   Voice: (202) 377-4180        BITNET: HIS@NIHCU         /
  65. /   Fax:   (202) 377-4614      INTERNET: HIS@CU.NIH.GOV    \
  66. \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
  67.