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]
st: RE: AW: Problems that seem to be the result of a "long command line" in a do file
From
"Hoogendoorn, Adriaan" <[email protected]>
To
"[email protected]" <[email protected]>
Subject
st: RE: AW: Problems that seem to be the result of a "long command line" in a do file
Date
Wed, 16 Jun 2010 00:12:13 +0200
Dear Martin,
Thank you for pointing out the "set trace on" option.
Running the command with the "set trace on" option generated an impressive amount of code, that confirmed my earlier guess that the "long command line" was somehow truncated.
At the same time the enormous amount of code made me humble enough to be not so picky and use the simple solution of renaming the original variables into shorter variable names. That was not so bad after all, and worked fine.
Tnx again,
Kind regards,
Adriaan Hoogendoorn
________________________________________
From: [email protected] [[email protected]] On Behalf Of Martin Weiss [[email protected]]
Sent: Tuesday, June 15, 2010 11:37 PM
To: [email protected]
Subject: st: AW: Problems that seem to be the result of a "long command line" in a do file
<>
" Do you know of a way I can run the first command?
I could use shorter variable names, but I am hoping for a more elegant
solution."
Maybe store the lists in -local-s and have them expanded within the call to
-confa-? What does -set trace on- tell you about the error?
HTH
Martin
-----Ursprüngliche Nachricht-----
Von: [email protected]
[mailto:[email protected]] Im Auftrag von Hoogendoorn,
Adriaan
Gesendet: Dienstag, 15. Juni 2010 23:31
An: [email protected]
Betreff: st: Problems that seem to be the result of a "long command line" in
a do file
Dear Statalist,
I encounter some problems that seem to be the result of a "long command
line" in a do file, even though I broke the long command line up into
several parts over several lines (see below).
The problem may be the result of my bad knowledge of Stata on this point.
I encounter the problem in a call to the 'confa' command in Stanislav
Kolenikov's package that does Confirmatory Factor Analysis (package st0169
from http://www.stata-journal.com/software/sj9-3).
The call:
confa (list_ae: ru001ae01 ru002ae02 ru003ae03 da001ae01 da002ae02 ///
da003ae03 vo001ae01 vo002ae02 vo003ae03 vo004ae04 ) ///
(list_ep: ru005ep01 ru006ep02 ru007ep03 ru008ep04 ru009ep05 ///
da005ep01 da006ep02 da007ep03 vo005ep01 vo007ep03 ) ///
(list_et: ru011et01 ru012et02 ru013et03 ru014et04 da011et01 ///
da013et03 da014et04 vo011et01 vo012et02 vo013et03 ) ///
, from(smart) iterate(50)
results into the error message "da0 ambigous abbreviation", while the call:
confa (list_ae: ru001ae01 ru002ae02 ru003ae03 da001ae01 da002ae02 ///
da003ae03 vo001ae01 vo002ae02 vo003ae03 vo004ae04 ) ///
(list_ep: ru005ep01 ru006ep02 ru007ep03 ru008ep04 ru009ep05 ///
da005ep01 da006ep02 da007ep03 vo005ep01 vo007ep03 ) ///
(list_et: ru011et01 ru012et02 ru013et03 ru014et04 ), from(smart)
iterate(50)
- which is identical to the first call, except that 'list_et' consists of
four instead of
ten variables - works fine.
Do you know of a way I can run the first command?
I could use shorter variable names, but I am hoping for a more elegant
solution.
Your help is very welcome.
Kind regards,
Adriaan W. Hoogendoorn
GGZ inGeest, Amsterdam
Dit e-mailbericht is uitsluitend bestemd voor de geadresseerde. Als dit bericht niet voor u bestemd is, wordt u verzocht dit aan de afzender te melden en het bericht te vernietigen. Het is niet toegestaan de inhoud van dit bericht verder te verspreiden of te gebruiken. Voor meer informatie over GGZ inGeest: www.ggzingeest.nl.
*
* For searches and help try:
* http://www.stata.com/help.cgi?search
* http://www.stata.com/support/statalist/faq
* http://www.ats.ucla.edu/stat/stata/