Notice: On March 31, it was **announced** that Statalist is moving from an email list to a **forum**. The old list will shut down at the end of May, and its replacement, **statalist.org** is already up and running.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

From |
David Elliott <dcelliott@gmail.com> |

To |
statalist@hsphsun2.harvard.edu |

Subject |
Re: st: RE: RE: xline on top of rarea |

Date |
Sun, 12 Sep 2010 13:01:16 -0300 |

While Vince's comments are very helpful, each added line requires specification of 4 coordinates, not 1, and more importantly one must know beforehand the plot boundaries for the other axis. There are ways to predict approximately where the boundaries are going to be through doing a -summarize- to find the r(min) and r(max), but if you are letting Stata automatically do the range, ticks and labels you may get surprised. There is the additional problem of plot margins to consider as well. As far as I am concerned -pcarrowi- and -pci- are merely kludges imitating a functionality that should exist in [x|y]line and suspect that Vince might agree. A little philosophical departure here: Graphs aren't drawn in just any old way. There is a specific logical sequence of laying down the "ink" in layers. First graph dimensions, margins, plot dimensions and margins are created and even if nothing is drawn, they are the first objects and determine the canvas and boxes into which all other objects are drawn. Then the axes and any gridlines are drawn. x and ylines are actually just individually specified gridlines and are written just following that layer. All plotting is performed over this basic structure, and if more than one plot is specified, each one writes over the previous layer as if it were physical ink. Finally text objects, labels, titles and legends are drawn since they mustn't be covered by plots. (I may be in error about a specific detail about the sequence but I believe what I have described here is essentially correct.) Creating overlaid x and ylines would mean treating them as non-grid objects, or perhaps more appropriately, as grid objects that are defined in the usual way, but have the option of being drawn after all plots have been drawn, but before any text objects. The way the graphing class system works I would hope that the x and yline objects could be defined as usual and a minor change made to where they were penned in - the [front|back] option I proposed previously. The xyline class objects appear to be created in a call to _gs_parse_and_log_lines.ado. I confess I can't follow things from there to see where they actually get penned but would be interested to know if someone can take the explanation further. DC Elliott On 11 September 2010 07:03, Martin Weiss <martin.weiss1@gmx.de> wrote: > > <> > > Also note the official statement from StataCorp at > http://www.stata.com/statalist/archive/2005-11/msg00702.html > > > > HTH > Martin > > > -----Original Message----- > From: owner-statalist@hsphsun2.harvard.edu > [mailto:owner-statalist@hsphsun2.harvard.edu] On Behalf Of Friedrich Huebler > Sent: Freitag, 10. September 2010 15:41 > To: statalist@hsphsun2.harvard.edu > Subject: Re: st: RE: RE: xline on top of rarea > > A front or back option for xline and yline would be useful. -pcarrowi- > is a solution but to have the same appearance as -xline- one must > specify the margins of the plot region and find the right coordinates > for the added line through trial and error. By default, graphs have a > margin between the inner and outer area of the plot region. The > -xline- option draws a line from the x-axis to the top outer margin of > the plot region. -pcarrowi- stays inside the inner plot region and > does not reach the margins of the outer plot region, unless that > margin is set to zero. This can be shown with the two graphs below. > > sysuse auto, clear > quietly regress mpg weight > predict hat > predict s, stdf > generate low = hat - 1.96*s > generate hi = hat + 1.96*s > > tw (rarea low hi weight, sort) /// > (pcarrowi -1 3000 41 3000, msize(zero)), /// > legend(off) xline(4000) /// > name(a) > > tw (rarea low hi weight, sort) /// > (pcarrowi -1 3000 41 3000, msize(zero)), /// > legend(off) xline(4000) /// > plotregion(margin(2 2 0 0)) name(b) > > Friedrich > > On Fri, Sep 10, 2010 at 8:43 AM, David Elliott <dcelliott@gmail.com> wrote: >> This is a common problem when using filled areas. It would make a >> great deal of sense to have a [x|y]line(####,[front|back]) syntax so >> the user could specify when in the process of drawing the graph >> objects the [x|y]line is drawn. This is why the -pcarrowi- approach >> works, one specifies it after the plot with the area fill options and >> plots are drawn in the order written. Frankly, I think Stata should >> have the option for the [x|y]line to be drawn on a plot after the >> other objects have been drawn and suspect the programming changes >> would be minor. >> >> DC Elliott * * For searches and help try: * http://www.stata.com/help.cgi?search * http://www.stata.com/support/statalist/faq * http://www.ats.ucla.edu/stat/stata/

**References**:**st: xline on top of rarea***From:*Friedrich Huebler <fhuebler@gmail.com>

**st: RE: xline on top of rarea***From:*"Martin Weiss" <martin.weiss1@gmx.de>

**st: RE: RE: xline on top of rarea***From:*"Martin Weiss" <martin.weiss1@gmx.de>

**Re: st: RE: RE: xline on top of rarea***From:*David Elliott <dcelliott@gmail.com>

**Re: st: RE: RE: xline on top of rarea***From:*Friedrich Huebler <fhuebler@gmail.com>

**RE: st: RE: RE: xline on top of rarea***From:*"Martin Weiss" <martin.weiss1@gmx.de>

- Prev by Date:
**st: RE: lrtest and wald or chi2 statistics** - Next by Date:
**RE: st: RE: RE: xline on top of rarea** - Previous by thread:
**RE: st: RE: RE: xline on top of rarea** - Next by thread:
**st: Re: How to tackle the r1400 error message** - Index(es):