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: Bug with destring or operator error?
From
"Ben Hoen" <[email protected]>
To
<[email protected]>
Subject
RE: st: RE: RE: Bug with destring or operator error?
Date
Thu, 22 Aug 2013 14:48:59 -0400
Yes, that indeed seems to have been an artifact of parmest, OR, at least NOT
destring.
Thanks guys!
Ben Hoen
LBNL
Office: 845-758-1896
Cell: 718-812-7589
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Nick Cox
Sent: Thursday, August 22, 2013 2:42 PM
To: [email protected]
Subject: Re: st: RE: RE: Bug with destring or operator error?
Joe and I had essentially the same notion. Stata internally gives
names to temporary variables that always have the double prefix __ and
continue with 6 digit suffixes 000001, etc. But if somehow you have
such a variable in your dataset there's a clash. It's difficult to say
why it exists but this is not to be considered a bug in -destring-.
Nick
[email protected]
On 22 August 2013 19:26, Ben Hoen <[email protected]> wrote:
> *So I added the following before the destring and it solved the problem!
> desc // the variable __000001 is listed there.
> drop __000001 //this did drop this variable
>
> *and then destring worked fine.
>
> *without the drop command it still hiccupped. See trace output below
> *FYI I used parmest (via SSC) to create the bgreg.dta dataset
> * I have no idea what that variable would have been it is not shown in the
> regression output.
> * in the dataset it is located between the p-value and the lower CI
*
* For searches and help try:
* http://www.stata.com/help.cgi?search
* http://www.stata.com/support/faqs/resources/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/faqs/resources/statalist-faq/
* http://www.ats.ucla.edu/stat/stata/