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

From |
"Nick Cox" <n.j.cox@durham.ac.uk> |

To |
<statalist@hsphsun2.harvard.edu> |

Subject |
st: RE: Req: Stata version in ssc archives |

Date |
Mon, 22 Aug 2005 19:43:26 +0100 |

I note from this that you have privately modified my program -fixsort- and now want advice on why it still works. The Statalist FAQ implies that once you modify a program, it is then yours and you are responsible for it! In this case, specifying -version 9- arose because of the internal use of the -clonevar- command. This was introduced in the lifetime of Stata 8, so anyone who has updated Stata 8 after 5 October 2004 should be in your situation: they can hack at the program and have the outcome you describe. Setting -version 9- is far from the only solution here but it was the laziest at the time I wrote -fixsort-. The situation with -blist- is different. The description at http://ideas.repec.org/c/boc/bocode/s419301.html is simply out-of-date in stating Stata 7, as the code now there specifies Stata 9, although my guess is that Stata 8 would be sufficient. The one detail here I noticed is whether a type must be specified in -generate-ing a new string variable. I can't comment further. When you say that the required version represents the minimum requirements needed by the command to work this is indeed the main idea. But it is also possible for a programmer to specify, whether by accident or design, either a version that is higher than this or a version that is lower than this. This could arise for all sorts of reasons. Here are three examples. They are far from exhaustive. 1. A programmer is developing a program under Stata 9. They thus believe that it works under Stata 9. They have no time or interest in going back to Stata 8, or another version, to check that it would also work under that version. Perhaps it will, perhaps it won't, but they can't bothered to check that out. 2. Perhaps the help file was developed for a later version. That is, the program might work in an earlier version, but the help file won't show properly because it uses a later version of SMCL. 3. A programmer could set say -version 8- and then accidentally use some feature of version 9 -- and not notice that -version 9- is required. This is the opposite of #1. Otherwise put, programmers are busy people too and often make short-cuts or consider their own convenience. Nick n.j.cox@durham.ac.uk Roberto De Miguel > Making - ssc whatsnew - I found the command "blist" > ............ > BLIST > module to list values of variables in as small a space as possible > Authors: Adrian Mander Req: Stata version 7.0 > > Revised: 2005-07-31 > ............ > > For my surprise, although it said: Req: Stata version 7.0, > when attempting > to use it requested the version 9 of Stata. > > Looking at the ado, I found that if I changed the line "version 9.0" > meetly, it also runs in a previous version of Stata. > > Something similar happened to me with the "fixsort" command > that although > it require the version 9.0 can be used in a previous version changing > the line that declares the version in the ado > ............ > FIXSORT > module to sort variables and align in sorted order, with others fixed > Authors: Nicholas J. Cox Req: Stata version 9.0 > > Created: 2005-08-02 > ............ > > I always understood that the required version represent the minuimum > requirements needed by the command to work. Isn't this correct? > > Can somebody clear up this point? * * 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: RE: Req: Stata version in ssc archives***From:*Adrian Mander <Adrian.Mander@mrc-hnr.cam.ac.uk>

- Prev by Date:
**Re: st: Deciles and Stata** - Next by Date:
**st: RE: RE: Turning Graph Legend Off** - Previous by thread:
**st: Req: Stata version in ssc archives** - Next by thread:
**Re: st: RE: Req: Stata version in ssc archives** - Index(es):

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