Stata The Stata listserver
[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]

st: RE: RE: Lining up and loopy logic


From   "Nick Cox" <n.j.cox@durham.ac.uk>
To   <statalist@hsphsun2.harvard.edu>
Subject   st: RE: RE: Lining up and loopy logic
Date   Thu, 11 Dec 2003 13:20:51 -0000

I just wrote this. I make one amendment below. 

Nick 
n.j.cox@durham.ac.uk 

> Allan Reese
> 
> > On Wed, 10 Dec 2003, Nick Cox wrote:
> > > Once you start changing the design by introducing
> > > options to fix things in absolute coordinates
> > > as well, it's my guess that's way beyond "not
> > > difficult"; it's out of the question in terms
> > > of the resulting complexities for programmers,
> > > and ultimately for users.
> >
> > Anything that is logical can be programmed.  Whenever
> > anyone tells you
> > that something "cannot be done because the computer doesn't
> > allow it",
> > it is a fudge and a cop-out.  All I asked for is the
> > ability to fix the
> > width of the inner graph region instead of it being
> > calculated internally.
> 
> And that ability is, if possible, certainly desirable.

That was sloppy writing on my part. The ability is desirable, 
irrespective of whether it is possible. 

> 
> I don't think I've ever used such an expression ("cannot
> be done...").
> 
> The issue is not what's possible in principle, but what's
> practicable, bearing in mind, among other things, the
> complexity of the
> resulting syntax. (The syntax for the new graphics
> is already fairly complicated, to say the least.)
> StataCorp may want to comment.
> 
> >
> > Since the question of when to use loops came up recently, 
> here is an
> > example of a technique that may be widely useful for
> > building overlaid
> > graphs.  The code that precedes has generated an indefinite
> > number of
> > variates defining lines for groups of points: _l1, _l2 etc.
> >  Groups are
> > identified by a factor, and while the x values will be
> > ascending within
> > each group there is no requirement for the start of value
> > of the next
> > group to be smaller, so connect(L) will not work.  The
> > following code
> > generates a command line by appending a line plot for each
> > group.  Then
> > the macro is executed.
> >
> > * Build and execute graph command ... as a very long macro text!
> >   loc colours="black black blue blue dkorange dkorange /*
> >             */ magenta magenta emerald emerald"
> > * Here's the point plot ...
> >   loc gr "scatter `y' `x', yti("`y'")"
> >   forvalues i = 1 / `maxgrp' {
> >     loc gr ///
> >        "`gr'||line _l* `x' if `by'==`i', clc(`colours') 
> legend(off)"
> >   }
> >   `gr' // execute macro command
> >
> > Comments:
> >
> > (1) I hve been unable to find out the maximum length for a
> > macro string,
> > but some very silly examples (too many groups) appear to
> > work.  The actual
> > code has rather more options for each graph
> 
> . help limits
> 
> or [R] limits are sources of guidance on limits.
> 
> In this general terrain, another method
> is to -separate- the variables and call -scatter-
> (or whatever) in a single call.
> 
> separate y, by(byvar)
> scatter `r(varlist)' x
> 
> If you have a long text string, don't use =.
> There is no need to evaluate a string like
> "black black blue blue dkorange dkorange magenta
> magenta emerald emerald" and you can get longer
> strings by avoiding evaluation.
> 
> Nick
> n.j.cox@durham.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/



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