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

st: RE: RE: FW: RE: RE: Problem with legend option - bug?


From   "Dupont, William" <william.dupont@vanderbilt.edu>
To   <statalist@hsphsun2.harvard.edu>
Subject   st: RE: RE: FW: RE: RE: Problem with legend option - bug?
Date   Mon, 21 Feb 2005 15:51:25 -0600

Nick

My understanding from reading David's email and the Stata documentation
is that nesting the -legend- option within the -by- option is necessary
(or at least highly desirable) for programming reasons.  It does not,
however, make for the easiest syntax from the user's perspective.  My
suggestion of a warning message was based on the assumption that this
would be the easiest way for Stata to help users from getting stuck
without requiring a lot or reprogramming on Stata's part.

Your delineation of the parser's job is fine.  If for esthetic or other
reasons it is deemed desirable to limit its role to these four areas
then I for one would prefer to outlaw the use of options or suboptions
that will be ignored.  For example, suppose I want  scatter plots of y
and z against x for separate values of a classification variable t.  If
I want this graph to have a legend of a single column in the upper left
hand corner of the graph I must issue a command like

    . scatter y z x , legend(col(1))  by(t, legend(position(11)))

The -col- option must be in the unnested -legend- option and the
-position- option must be in the nested -legend- option.

    . scatter y z x , legend(col(1) position(11))  by(t) 

ignores the -position- option while

    . scatter y z x ,  by(t,legend( position(11) col(1)))

ignores the -col- option. The Stata parser often gives helpful hints
when I make an error.  If it is too hard to simplify the syntax, then it
would be more user-friendly to forbid suboptions in locations where they
will be ignored and give an indication as to where these suboption
should be placed.  Doing this would not violate your definition of the
parser's role.

The preceding examples are all rather obscure.  However, the unexpected
response to a command similar to

    . scatter y z x , legend(off)  by(t) 

is one that I stumbled across in a real example.  I personally would
have prefer this command to generate syntax error directing me to nest
my -legend- in my -by- option. I found the current behavior of just
ignoring the -legend- option to be confusing.

Bill

-----Original Message-----
From: owner-statalist@hsphsun2.harvard.edu
[mailto:owner-statalist@hsphsun2.harvard.edu] On Behalf Of Nick Cox
Sent: Monday, February 21, 2005 2:21 PM
To: statalist@hsphsun2.harvard.edu
Subject: st: RE: FW: RE: RE: Problem with legend option - bug?


This area of syntax is certainly 
troublesome while you are learning it, 
but I am not sure what Bill wants here. 

The parser has, as I understand it, 
one essential job with four components: 

1 parse what the user types into tokens 

2 decide if the whole is legal

3 issue an error message if not 

4 pass on for execution if so. 

What facilities are you requesting for 
the parser here? Some sort of advice 
or counselling facility? 

"Are you sure that you really mean to 
ask for that?" 

That goes way, way beyond what is the 
scope of the parser, in terms of either 
aim or ability. I can't see it as a 
job for any other part of the software
either.  

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