I have to admit that when I looked at a graph that included 0 with the
- -yscale(log)- option the first time, I thought that graph was doing
something wrong too. A bit of reflection reveals it is not doing
anything wrong, it is handling the mathematical fact that log(0) is
negative infinity as best it can. When you ask graphics to do a
- -yscale(log)- plot including 0 on the axis, everything else gets
smooshed up to the top, exactly as it should if you actually plotted
negative infinity in on your graph. To negative infinity, all finite
numbers look the same.
If your data includes 0, the graph is going to include log(0) on the
axis; there's no getting around it.
Consequently, I think your best option may be to use stphplot.
I don't think this is right - it's simply a question of getting the
software to start plotting at the first non-zero value of the cumulative
hazard in each group specified in the by() option, whenever the yscale(log)
option is specified. Jean Marie - if you type:Date: Tue, 27 May 2003 13:47:49 -0500
From:
Subject: Re: st: sts graph, na yscale(log) vs stphplot
"JAC Sterne, Social Medicine" <[email protected]> wrote
Stata provides two graphical methods to assess the proportional
hazards assumption (1) graphing the cumulative hazards on a log
scale using -sts graph, na yscale(log) or (2) using the stphplot
command. Although the point estimates are derived in different ways
these two methods are equivalent because log(cumulative hazard) is
the same as log(-log(survival).
I prefer (1), because it is easier to understand why graphs of
log(cumulative hazard) should be parallel if the proportional
hazards function is true. However, there seems to be a problem with
the graph produced by sts graph, na yscale(log) in Stata 8. Because
the cumulative hazard (by definition) starts at 0, the graph gets
squeezed up to the top unless you start plotting beyond the time of
the first event using the tmin() option. And when comparing
cumulative hazards in several groups this means starting beyond the
minimum time in all groups, which if one of the groups is small may
mean omitting much of the data.
Have I (a) misunderstood, or (b) missed an easy workaround? Or is
this a bug/feature requiring improvement?
