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
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
-ciplot- and now
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
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
-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
alone shows me whatever -predict- produces
by default as a dropped line plot with one
axis _n. And with -regress- that is fitted values.
. 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
. 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
syntax <stuff> , <specified_options> *
<preparation of variables to plot>
graph <stuff> , <some_options> `options'
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
predict ... , `options'
graph ... , <specified_options>
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
all I want to do is have two wildcarded
sets of options,
or I need another syntax.
Put one or both sets of options in bags.
Syntax could be, modulo details not pertinent,
indexplot [ , graph(<graphics_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.
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"
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
Hence the possibility I chose. Any bright
ideas or comments?
* For searches and help try: