[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: -indexplot- updated for Stata 8 on SSC |

Date |
Fri, 14 Feb 2003 13:59:15 -0000 |

Thanks to Kit Baum, the -indexplot- package has been updated on SSC for Stata 8. First a few general comments: The advent of Stata 8, and in particular its major new graphics functionality, has drastic implications for most previous user-written graphics add-ons. Many are superseded by new commands, or made obsolete by new features of new commands, and so must be consigned to the oblivion of history, together with MS-DOS, Rubik's cubes, Monkees albums, hula hoops and zoot suits -- except of course if you are using Stata 7 or some other previous version. However, looking through the wreckage wrought among my own graphics add-ons, for example, some programs seem to retain their rationale. Bryan Sayer's posting yesterday may represent others who have only just upgraded to Stata 8 -- or may be about to do so in the near future -- in wanting to know what user-written extras are now available for that release. The list of such graphics programs of mine is -pairplot- -cycleplot- -skewplot- -ciplot- and now -indexplot- In each case, previous versions still exist for Stata 6 (and thus 7) or for Stata 7 on SSC, under different names, but will not be developed further by me. Anyone who tries this with their own graphics programs will find that it's more than a matter of getting inside the code and translating the graphics calls. In particular, the new graphics provides all sorts of new possibilities for extending the functionality of programs relatively easily. At the same time, in opening up the code of some old programs, I have felt free to clear away what now looks all too much like kludge, fudge, ugly syntax or blurred focus. Hence any users of my old programs may find that they need to note a new syntax. Turning to -indexplot-, this is one of a suite of post-model graphics programs with general approach discussed in a couple of talks, the overheads of which are accessible at http://www.stata.com/support/meeting/8uk/diag.pdf (words) http://www.stata.com/support/meeting/8uk/diag.html (music) -indexplot- plots estimation results (by default whatever -predict- produces by default) from an immediately previous -regress- or similar command versus observation number (i.e. _n). Values are shown, by default, as dropped lines starting at 0. -indexplot- has an idiosyncratic syntax of the form . indexplot [options] [, more_options] Let me explain through examples: . sysuse auto . regress mpg weight . indexplot alone shows me whatever -predict- produces by default as a dropped line plot with one axis _n. And with -regress- that is fitted values. In . indexplot, base(mean) the option is as a graphics option. -indexplot-'s -base()- is a minute generalisation of -twoway dropline-'s -base()- option, and here just specifies that the mean of whatever is being shown should be base for the dropped lines. On the other hand, . indexplot residual is in fact an option call (!) to -predict- to say: "Don't show your default. Show me the residuals instead", while . indexplot residual, hi(3) lo(3) mla(make) also says "use the graphics option -mlabel()- and the options -high()- and -low()-" (explained, naturally, in the help). . indexplot cooksd, hi(6) mla(make) shows a similar mix, as do further examples: . glm mpg weight, link(log) . indexplot anscombe, hi(3) lo(3) . sysuse census . regress marriage pop . indexplot dfbeta(pop), mla(state) The -glm- example flags a more general point. This program is _not_ restricted to use after -regress- (and possibly -anova-) as are the official Stata suite documented at -help regdiag-. Why did I flout standard syntax in this way? !!! Technicalities ahead warning ================================ The remainder of this posting may be of interest to some Stata programmers only. The programmer's problem, here made a problem for the user, is handling two rather large sets of options simultaneously, those for -predict- and those for -twoway-. One way to set up a graphics add-on used to be program def myplot version 7 syntax <stuff> , <specified_options> * <preparation of variables to plot> graph <stuff> , <some_options> `options' end so that the user can still specify all sorts of -graph- options. In previous versions of -indexplot- I used the wildcard * for -predict- options, several of which are estimation command- specific and documented at various places: I refuse to go through the manuals trying to find them all (or trying to grep them from .hlp files). Thus I had program def indexplot version 7 ... predict ... , `options' ... graph ... , <specified_options> end This had clear limits. Users would email me, saying I have my -indexplot-, and I am trying to modify the graph, but I get a bizarre error message -- which was because their -graph- option was being rebuffed by -predict-. Not good. So all I want to do is have two wildcarded sets of options, or I need another syntax. Possibility 1 ============= Put one or both sets of options in bags. Syntax could be, modulo details not pertinent, indexplot [ , graph(<graphics_options>) predict(<predict_options>) ] So the user has to type . indexplot , graph(mla(make)) predict(dfbeta(weight)) Advantage. Close to standard syntax. Options follow the comma. Advantage. Inside the program programmer can unpack each bag very easily. Disadvantage. User has to learn what to put in each bag. Disadvantage. User has to change habits. Is just getting used to being able to add -mla(make)- when ornery user-written program insists that has to go in a bag. Disadvantage. I think it looks horrible. Possibility 2 ============= Command plus subcommand syntax. Syntax could be, modulo details not pertinent, indexplot predict_option [ , <graphics_options> ] Advantage. This looks quite good as long as you can use a single obvious word for what is a thinly disguised predict_option (e.g "residual" is OK). Advantage. Increasingly, many Stata commands have this form. Users should or will be getting familiar with this form, except that usually the subcommand is a simple verb. Disadvantage. This can't be sustained for cases in which -predict- is fed two or more options. Hence the possibility I chose. Any bright ideas or comments? Nick n.j.cox@durham.ac.uk * * 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: -indexplot- updated for Stata 8 on SSC***From:*Antoine Terracol <Antoine.Terracol@univ-paris1.fr>

**References**:**st: including all interactions among a set of variables***From:*"david huffer" <dhuffer@crim.umd.edu>

- Prev by Date:
**st: problems wih stata maximize** - Next by Date:
**st: RE: -indexplot- updated for Stata 8 on SSC** - Previous by thread:
**st: RE: including all interactions among a set of variables** - Next by thread:
**Re: st: -indexplot- updated for Stata 8 on SSC** - Index(es):

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