That's helpful.
Thanks for the compliment. Every Stata guru has Stata gurus. Mine here
are Bill Gould and Vince Wiggins of StataCorp.
Bill set up the original -graph- with various biases; most he knew about
and a few he didn't. -graph- before 8 had one positive bias: it was very
flexible for anything like a scatter plot. Thus one grew up wanting to do
stuff, and it was easy whenever that stuff could be done as a special kind
of scatter plot. (Even a histogram can be drawn in such a way: the data
points are the bar corners; you just need to join them up in one special
order....) This was, also, a limitation, but being obliged to think
in terms of scatter plots and their kin has many benefits.
Vince is principal architect of Stata's new graphics. He has taught me
several nice tricks over the years. At his feet I sit and on his shoulders
I stand. He'd find the former position more comfortable than the latter.
Vince (with Alan Riley and others) created a system whose potentialities
we are still discovering. Excellent programmers create a program that
does exactly what they want, with few bugs and a few nice features.
Outstanding programmers create programs that can do even more than
they wanted or imagined.
OK, let's try to solve some problems.
On your first, I don't have a clear idea of your
data structure, but if there is a big hint it's to
give up on -graph dot- or -graph bar- or -graph hbar-
when things get too complicated and recast the problem
using -twoway-. (The similarity to the <8 situation is
not accidental.) Perhaps you are doing this already.
On your second, I get a clearer sense of what niggles.
My hint here is that often you don't to change anything
so long as the axis labels tell the story you want.
(Axis titles and other text must also tell the truth as
you want the reader to see it.)
Suppose you have a response that to Stata is a proportion in
[0,1] but that you want shown on a percent scale. Then something
like
yla(0 0.2 "20" 0.4 "40" 0.6 "60" 0.8 "80" 1 "100")
gets the labels you want and what the data are, really,
underneath is not important. Something like this can be
a little tedious, so one shortcut is -mylabels- on SSC
with which you can do
mylabels 0(20)100, myscale(@/100) local(labels)
... , yla(`labels')
That is, you tell -mylabels- that you
1. want certain text labels to be shown
2. have data that is on a different scale, and
give the mapping from one scale to another
3. want the labels put in a local macro.
It can be a close call, but this often saves
typing in the long run, especially with scales
more complicated than percents or proportions,
partly because in practice one often gets
slowed down by silly little typos when you do
it the direct way.
Nick
[email protected]
Fred Wolfe
> I reply with great deference. Nick is the master of graph programs.
>
> Perhaps I am wrong about the difficulty of this task.
>
> Consider subjects who take one or more of 10 drugs at two time
> periods. I want to show the proportion of subjects taking each of the
> drugs at time 1 and time 2.
>
> Drug 1 .................X................Y.........
> Drug 2 ........................X..Y................
> Drug 3 .. etc
>
> If each drug was a category within "alldrugs" I could do this easily
> (over(alldrugs)). Because this is not the case, I have to overlay two
> graphs, perhaps fiddle with scaling, and maybe multiply variables,
> and so on. Have I missed something easy?
>
> With respect to multiplying by 100, here's what I think I have to do.
> Either clone the variables of interest and multiply them by 100 or
> preserve, multiply, make the graph, restore. While this is a trivial
> task, it is also a nuisance.
>
> The issue that I am raising is not that these tasks are not doable,
> but that it takes time to do them. Sometime a lot of time if one is
> not so facile or if one is working with multiple data sets. I would
> rather spend time analyzing data than fiddling with graph code. So,
> it would be nice if a graph book could address a series of
> simplifying issues like this. Stata, lets me type -or- after logit or
> clogit so that I don't have to take the time to do exponentiate
> separately. Stata doesn't yet allow similar ease of use extensions
> such as I have specified.
>
> I hope I haven't missed something very easy. Michael Mitchell's book
> might add additional value by addressing a series of issues such as
> these and showing programs such as you have written to
> facilitate graphing.
>
> Fred
>
> At 12:34 PM 7/25/2007, you wrote:
> >Fred Wolfe replied to Michael Mitchell's request for suggestions
> >on a second edition of "A Visual Guide to Stata Graphics" with
> >several thoughts from his experience.
> >
> >I have extracted two comments here, which should be of
> >interest beyond the book and before any second edition appears:
> >
> > > For bar and dot graphs, orientation is almost exclusively
> to over()
> > > and by(). But I often have to make such graphs under circumstances
> > > where over groups are not mutually exclusive. For
> example, instead of
> > > having an over group for drugs that patients might take, I have
> > > situations where patients take more than one drug, making the over
> > > group option useless to me. So I would very much like to see an
> > > expanded section on handling overlapping groups - or non-grouped
> > > data. Too much group stuff for me, but perhaps not for others.
> >
> >I am not clear what the difficulty here is at all. Please give
> >a specific example or more detail.
> >
> > > Converting proportions to percentages is a frequent task. Maybe
> > > adding some lines of code to do simple tasks like this would be
> > > helpful.
> >
> >Sorry, but what's the complication to be explained here?
> >Multiplication by 100?
*
* 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/
