Bookmark and Share

Notice: On April 23, 2014, Statalist moved from an email list to a forum, based at statalist.org.


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

RE: st: RE: RE: xline on top of rarea


From   "Martin Weiss" <[email protected]>
To   [email protected]
Subject   RE: st: RE: RE: xline on top of rarea
Date   Sun, 12 Sep 2010 18:28:38 +0200

<>
I am putting all my money on sergiy being able to explain this further.

HTH
Martin

-original message-
Subject: Re: st: RE: RE: xline on top of rarea
From: David Elliott <[email protected]>
Date: 12-09-2010 18:02

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 <[email protected]> wrote:
>
> <>
>
> Also note the official statement from StataCorp at
> http://www.stata.com/statalist/archive/2005-11/msg00702.html
>
>
>
> HTH
> Martin
>
>
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of Friedrich Huebler
> Sent: Freitag, 10. September 2010 15:41
> To: [email protected]
> 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 <[email protected]> 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/


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


© Copyright 1996–2018 StataCorp LLC   |   Terms of use   |   Privacy   |   Contact us   |   Site index