[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]

From |
Jonathan Sterne <[email protected]> |

To |
[email protected] |

Subject |
st: more on sts graph, na yscale(log) |

Date |
Wed, 28 May 2003 10:23:56 +0100 |

In response to my question about sts graph, na yscale(log) Jean Marie Linhart ([email protected]) wrote:

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

version 7.0

sts graph, by(groupvar) na ylog

you will find that this is exactly what happens. It was the change to version 8 that introduced the problem.

Best wishes

Jonathan Sterne

Original query follows:

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]> wroteStata 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?

---------------------- Jonathan Sterne Department of Social Medicine University of Bristol Canynge Hall, Whiteladies Road Bristol BS8 2PR Phone 0117 928 7396 Fax 0117 928 7325 E-mail [email protected] web www.epi.bris.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/

- Prev by Date:
**st: looping through vectors** - Next by Date:
**st: RE: looping through vectors** - Previous by thread:
**st: Why `sums'[_N] in stata module kernreg1** - Next by thread:
**Re: st: more on sts graph, na yscale(log)** - Index(es):

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