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

RE: RE: revising -rename- [was:RE: st: quick question]


From   "Nick Cox" <n.j.cox@durham.ac.uk>
To   <statalist@hsphsun2.harvard.edu>
Subject   RE: RE: revising -rename- [was:RE: st: quick question]
Date   Thu, 26 Feb 2004 17:58:17 -0000

I'm not clear on your point here. I'd parse 
the list immediately after -syntax- and before 
doing any serious work. 

I see two possibilities for unpaired name lists. 

1. The user made a mistake. 

2. The user is just throwing names at 
your option with the conscious view that 
one too many doesn't matter. 

I'd be surprised at #2, but I can't rule 
it out; more importantly, I wouldn't indulge 
either possibility, as a program writer, and I 
wouldn't want a program to indulge either, as a user. 

Certainly, nothing like this is indulged in 
-renvars-. For example, all supposedly existing names 
must exist beforehand, and all supposedly new names 
must be available beforehand. -renvars- does nothing
unless that is true.  

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

Roger Newson
> 
> At 16:28 26/02/04 +0000, Nick Cox wrote:
> >If that were my program I would throw the request
> >straight back at the user. I would never indulge
> >a list with an odd number of names.
> >
> 
> The reason -parmest- and -parmby- don't throw the request 
> back is that they 
> are often used in programs which call an estimation command 
> which takes a 
> non-trivial amount of real time to converge. I would not want 
> to throw away 
> all that work just because the user has inadvertently 
> specified an extra 
> name to -rename()- . However, I would agree that an 
> error-level diagnostic 
> is the way to go if an odd number of names is given to a Syntax 2' of 
> -rename-. (And possibly even for -descsave-.)
> 

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