home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / bit / listserv / sasl / 5450 < prev    next >
Encoding:
Text File  |  1992-12-22  |  3.0 KB  |  65 lines
  1. Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
  2. Path: sparky!uunet!paladin.american.edu!auvm!BARUCH.BITNET!TEJERA
  3. Message-ID: <SAS-L%92122114531958@UGA.CC.UGA.EDU>
  4. Newsgroups: bit.listserv.sas-l
  5. Date:         Mon, 21 Dec 1992 14:44:46 EST
  6. Reply-To:     Philip Tejera <TEJERA@BARUCH.BITNET>
  7. Sender:       "SAS(r) Discussion" <SAS-L@UGA.BITNET>
  8. From:         Philip Tejera <TEJERA@BARUCH.BITNET>
  9. Subject:      Re: PROC SORT NODUPLICATES is no good
  10. In-Reply-To:  Message of Wed,
  11.               16 Dec 1992 19:48:41 EST from <76350.1604@COMPUSERVE.COM>
  12. Lines: 51
  13.  
  14. On Wed, 16 Dec 1992 19:48:41 EST Andy Norton said:
  15. >..
  16. >SUMMARY:   Phillip Tejera has not addressed the "adjacency" issue
  17. >..
  18. Gee, Andy, I didn't realize I had committed such a crime! :-)
  19.  
  20. My purpose was more general. I thought the so-called "adjacency"
  21. issue was more than adequately covered in the SAS v5 Basics manual,
  22. the SAS v6 Procedures manual, and previous discussions on the list.
  23. I had no quarrel with your contention that the Language and Procedures
  24. manual was inaccurate. My question is, having shown the inaccuracy, why do
  25. you continue to want to believe the L&P manual?
  26.  
  27. Incidentally, despite your protests, your example did have only
  28. one key! It was clearly not unique. I was heartened, however, that in
  29. your responses to Derek and me it was clear you took back most of what
  30. you said in your first posting. My main objection was to your Proc Sort
  31. by _all_ ;  . In your most recent posting you agree:
  32.  
  33. >                                         ...  I sort by _ALL_ to make
  34. >them adjacent, not for any other reason.  Yes this is expensive, but I
  35. >need to make them adjacent in order to delete exact duplicates.
  36. >
  37. >Note:  in real life I don't really ever do this.  I keep keys, and
  38. >remove duplicates on those keys.  But ...
  39.  
  40. If you don't do it, why do you recommend it to SAS-L's world-wide
  41. readership. Get real!
  42.  
  43. My point in discussing the concept of a unique key or set of keys was
  44. to provide a basis for clarifying the context of the issue. If you
  45. have observations that are supposed to be unique as to key, but in
  46. fact have duplicates, erroneous data have crept into your study.
  47. The Noduplicates option of Proc Sort is one conservative way to clean
  48. the data in the course of sorting it.
  49.  
  50. It is no news that it is NOT GUARANTEED to remove all exact duplicates.
  51. But I strongly disagree with your procedure for eliminating duplicate
  52. keys using Nodupkey and the sort by _all_; .
  53.  
  54. If I had occasion to sort the data, I would use the Noduplicates option;
  55. this would be efficient since I was already doing the sorting.
  56. But more importantly, I would do a Univariate or Freq on the unique
  57. key or set of keys, SO AS TO VERIFY THAT THEY ARE INDEED UNIQUE. Lines
  58. or cells with a count greater than one would immediately identify the
  59. problem observations.  Having identified them, I could then print them
  60. out, or better, examine them interactively. Having done sufficient
  61. checking, it is then a simple matter to use SAS's Delete or Where
  62. statements to eliminate the erroneous observations.
  63.  
  64. And, of course, this does not require the notorious "adjacency".
  65.