st: RE: RE: Lining up and loopy logic

 From "Nick Cox" To 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
> >
> >
> > (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/
```