Stata The Stata listserver
[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]

st: -indexplot- updated for Stata 8 on SSC

From   "Nick Cox" <>
To   <>
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 

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
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

-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. 

    . 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' 

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> 

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. 

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 

Hence the possibility I chose. Any bright 
ideas or comments? 


*   For searches and help try:

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