[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]

From |
"Nick Cox" <[email protected]> |

To |
<[email protected]> |

Subject |
RE: st: STATA Vs. SAS |

Date |
Wed, 27 Nov 2002 21:20:08 -0000 |

Richard Herrell > In SAS (and dBase or SPSS, e.g.), these commands are > evaluated for each > observation. In such a structure, once a true condition is met, > subsequent conditions are skipped. Say I want to assign > grades to my > students' percentage scores. In SAS I could write > > if score > 90 then grade='A'; > else if score > 80 then grade='B'; > else if score > 70 then grade='C'; > else if score > 60 then grade='D'; > > SAS will assign the appropriate grade to the first > condition that is true, > then skip the following conditions in the structure. (This > is also true > of other database management languages I've used such as > dBase.) This is > why I find it more efficient and less cumbersome than > writing the complete > condition for a series of "if ... then"s when every one > will be evaluated. > > I think this is steering dangerouly close to "how do you do > it in SAS" > talk, but I did want to illustrate one way that I find > Stata less easy to > use than SAS. > OK. For some of these problems you can avoid -if- altogether. I might do the score-grade conversion this way gen str1 grade = substr("DCBA",int(score/10)-5,1) or this way gen grade = int(score/10) label def grade 9 A 8 B C 7 D 6 label val grade grade although by the time I have worked this out in my head I could have typed in a slower way and Stata would have done it all. It is true that in some circumstances Stata can be slowed down by repeated testing using -if-. Most of the time, it is so fast anyway that you might hardly notice, but this can become a big issue. A while back Michael Blasnik did some comparisons and found -in- much faster than -if- in situations where the two are alternative ways of doing it. (I hope I summarise his results correctly.) This is a somewhat neglected topic. We'll still comparing Stata and SAS, as I see it. A speed comparison would need at least the same problem on the same hardware. Speed, for the user, must include coding and typing time, but then we would need people equally proficient in SAS and Stata to compare: perhaps that thought should stop there. Nick [email protected] * * For searches and help try: * http://www.stata.com/support/faqs/res/findit.html * http://www.stata.com/support/statalist/faq * http://www.ats.ucla.edu/stat/stata/

**Follow-Ups**:**RE: st: STATA Vs. SAS***From:*Fred Wolfe <[email protected]>

**References**:**RE: st: STATA Vs. SAS***From:*Richard Herrell <[email protected]>

- Prev by Date:
**RE: st: STATA Vs. SAS** - Next by Date:
**RE: st: STATA Vs. SAS** - Previous by thread:
**RE: st: STATA Vs. SAS** - Next by thread:
**RE: st: STATA Vs. SAS** - Index(es):

© Copyright 1996–2024 StataCorp LLC | Terms of use | Privacy | Contact us | What's new | Site index |