Quantcast

Stata 12: wish list

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Stata 12: wish list

Richard Ohrvall
I do not know if requests for features in the coming version of Stata
is of any use, but since it seems as if the Stata people are reading
this list and they seem like nice people, I take my chance.

I would really like a better support for creating tables in the next
version of Stata. By this I mean an output of tables that is easily
imported into Word or any other word processor. I would also like to
see a bit more flexibility in the table commands. To me it is a bit
surprising that you e.g. can't control the number of decimals in the
output of -tab-. This is very annoying when you want to see a
proportion with a specific number of decimals. All other major
statistical programs seem to be ahead of Stata in these aspects. Yes,
I know that there are user-written programs that do these things, but
these seem like basic functions that should be included in the
program. One solution could be an optional output window (like the
graph window), so that those who want to keep the present design and
output could do so.

All the best,
Richard
*
*   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/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Stata 12: wish list

Thomas Speidel
While I understand the intricacies of such a task, for me too this has  
been on the wish list for some time.  Judging from the number of  
user-written programs, the presentations at user group meetings and  
conferences and how Some Alternative Sofwtare (don't remember who came  
up with this acronym) fares in this area, I suspect the folks at Stata  
are taking notice.  I am not sure how far up this topic is in the  
priority list.

One common response I hear is that solutions exists in the form of  
user written programs.  There is a large number of great work (Ian  
Watson, John Gallup, Michael Lokshin, Ben Jann, Roger Newson to name a  
few authors).  But these tend to be ad-hoc solutions:  some only  
handle a certain type of data, some will display p-values but no  
confidence intervals, etc etc. This in my view has the side effect of  
forcing the user to either write his or her program, or produce the  
tables from scratch in Excel/OpenOffice/Latex.

Making more estimates available after estimation and more results  
stored in locals in general could perhaps be a good starting point.  
Eventually, I would love to see more automation in this area from Stata.

--
Thomas Speidel

Quoting Richard Ohrvall <[hidden email]> Mon  1 Nov 14:15:54 2010:

> I do not know if requests for features in the coming version of Stata
> is of any use, but since it seems as if the Stata people are reading
> this list and they seem like nice people, I take my chance.
>
> I would really like a better support for creating tables in the next
> version of Stata. By this I mean an output of tables that is easily
> imported into Word or any other word processor. I would also like to
> see a bit more flexibility in the table commands. To me it is a bit
> surprising that you e.g. can't control the number of decimals in the
> output of -tab-. This is very annoying when you want to see a
> proportion with a specific number of decimals. All other major
> statistical programs seem to be ahead of Stata in these aspects. Yes,
> I know that there are user-written programs that do these things, but
> these seem like basic functions that should be included in the
> program. One solution could be an optional output window (like the
> graph window), so that those who want to keep the present design and
> output could do so.
>
> All the best,
> Richard
> *
> *   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/
>



--
Thomas Speidel


*
*   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/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Stata 12: wish list

Sridhar Telidevara
I would like to point out one more dimension where some improvements
can be done. Superimposing mean/median/mode values in a box plot is
something what I feel STATA should implement. I had terrible
experience with use written programs.

Sridhar
*
*   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/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Stata 12: wish list

cmagazzino
Hi!
I would like that Stata enhance some time-series techniques, such as
Granger-causality after a VECM, FMOLS model, non-linear Granger-causality.

Best wishes!

--
COSIMO MAGAZZINO
DIPES
School of Political Sciences
Roma Tre University
Via G. Chiabrera 199, 00145, RM
tel.: +39 0657335347
fax: +39 0657335282

*
*   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/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Stata 12: wish list

nshephard
Administrator
In reply to this post by Thomas Speidel
Thomas Speidel wrote
One common response I hear is that solutions exists in the form of  
user written programs.  There is a large number of great work (Ian  
Watson, John Gallup, Michael Lokshin, Ben Jann, Roger Newson to name a  
few authors).  But these tend to be ad-hoc solutions:  some only  
handle a certain type of data, some will display p-values but no  
confidence intervals, etc etc. This in my view has the side effect of  
forcing the user to either write his or her program, or produce the  
tables from scratch in Excel/OpenOffice/Latex.
The problem with this though is that there is no way of anticipating what an individual will think is most appropriate.  Personally I'd plump for LaTeX, but I'm sure others wouldn't.  There will always be something that one person uses that isn't supported and "should be".

The user-written commands are very flexible and exceptionally useful and I'm very grateful to the various authors for developing them in the first instance, sharing them and continuing to develop them.

Having to write your own program to produce the desired table is not a bad thing, and after you've done it once you'll find you can re-use your code.  It may even evolve into a ado-file that you can then share with the rest of the world.

This is a good thing to my mind.

Personally I would rather see Stata development focus on statistical issues than presentation issues as they are far more common to all users.

Thomas Speidel wrote
Making more estimates available after estimation and more results  
stored in locals in general could perhaps be a good starting point.  
Most commands leave behind a lot of results in scalars and matrices that can be utilised afterwards.  See -man return- for full details.  I rarely find there is anything lacking from these.

Neil
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Stata 12: wish list

Nick Cox
In reply to this post by Sridhar Telidevara
Hmmm... "terrible" is a pretty strong word. It's a word I use if I hear that a friend has lost a parent, or been dumped by a partner, or whatever. Frustrating, disappointing, ...: that I can believe.  

It's difficult to address specific details here, because there aren't any, but nevertheless various comments are possible.

0. Means on box plots are a graphical mixed metaphor, and arguably an admission that the box plot is not informative enough, but let that be.

1. I am not sure that there is any up-to-date user-written program specifically designed to draw box plots. -hbox- from SSC meets the second part of the prescription, but it's way out-of-date and of no interest unless you are on Stata <8. -stripplot- from SSC has an option of adding a box, but it's not designed to do what is being described here. You could get close through its -addplot()- option, but that's a longer story.

2. Some other programs [Sridhar did use a plural] may be in mind here, but I can't comment.

3. User-programmers tend to write programs for themselves, with no guarantee of meeting anyone else's needs, so I guess that might seem perverse of them.

4. But this is all immaterial. You don't need any user-written programs to add means to box plots. You can do it yourself with a few lines of Stata, as was explained in

SJ-9-3  gr0039  . . . . . . . . Speaking Stata: Creating and varying box plots
        . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  N. J. Cox
        Q3/09   SJ 9(3):478--496                                 (no commands)
        explains how to use egen to calculate the statistical
        ingredients needed for box plots and variations of box
        plots; shows the use of twoway to then create the plots

That doesn't stop StataCorp being persuaded into adding this as an extra option.

As for median and mode: I see no need to add medians to box plots, as they are part of the design. Modes can easily be added using the principles above provided you can come up with a recipe to calculate them. (-hsmode- from SSC is one such.)

Nick
[hidden email]

Sridhar Telidevara

I would like to point out one more dimension where some improvements
can be done. Superimposing mean/median/mode values in a box plot is
something what I feel STATA should implement. I had terrible
experience with use written programs.


*
*   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/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Stata 12: wish list

Robert A Yaffee
In reply to this post by cmagazzino
Cosimo,
  Have you seen a nonlinear-Granger causality test?
Lutkepohl does not refer to it.  How about fractional
VECM?
   - Robert

Robert A. Yaffee, Ph.D.
Research Professor
Silver School of Social Work
New York University

Biosketch: http://homepages.nyu.edu/~ray1/Biosketch2009.pdf

CV:  http://homepages.nyu.edu/~ray1/vita.pdf

----- Original Message -----
From: [hidden email]
Date: Tuesday, November 2, 2010 4:01 am
Subject: Re: st: Stata 12: wish list
To: [hidden email]
Cc: [hidden email]


> Hi!
> I would like that Stata enhance some time-series techniques, such as
> Granger-causality after a VECM, FMOLS model, non-linear Granger-causality.
>
> Best wishes!
>
> --
> COSIMO MAGAZZINO
> DIPES
> School of Political Sciences
> Roma Tre University
> Via G. Chiabrera 199, 00145, RM
> tel.: +39 0657335347
> fax: +39 0657335282
>
> *
> *   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/
*
*   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/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Stata 12: wish list

Sridhar Telidevara
The dual objectives of any  software like stata are to assist

1. Research, and

2. Presentation of the results obtained from the research.


I believe that the former is more difficult to design that suits
everybody's requirements. This is where I am flexible and I am full of
praise for stata modules and user programs.  However the latter is
easier and that is where lot of standardization can be made so that
researchers do not have to spend their time breaking their heads
figuring out how to insert mean in a box plot etc. I am sure most of
you would agree with me on this. I understand that not everything can
be perfected but we can push the horizons. Flexibility and
standardization are both important  for researchers.

Sridhar

On Tue, Nov 2, 2010 at 4:32 PM, Robert A Yaffee <[hidden email]> wrote:

> Cosimo,
>  Have you seen a nonlinear-Granger causality test?
> Lutkepohl does not refer to it.  How about fractional
> VECM?
>   - Robert
>
> Robert A. Yaffee, Ph.D.
> Research Professor
> Silver School of Social Work
> New York University
>
> Biosketch: http://homepages.nyu.edu/~ray1/Biosketch2009.pdf
>
> CV:  http://homepages.nyu.edu/~ray1/vita.pdf
>
> ----- Original Message -----
> From: [hidden email]
> Date: Tuesday, November 2, 2010 4:01 am
> Subject: Re: st: Stata 12: wish list
> To: [hidden email]
> Cc: [hidden email]
>
>
>> Hi!
>> I would like that Stata enhance some time-series techniques, such as
>> Granger-causality after a VECM, FMOLS model, non-linear Granger-causality.
>>
>> Best wishes!
>>
>> --
>> COSIMO MAGAZZINO
>> DIPES
>> School of Political Sciences
>> Roma Tre University
>> Via G. Chiabrera 199, 00145, RM
>> tel.: +39 0657335347
>> fax: +39 0657335282
>>
>> *
>> *   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/
> *
> *   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/
>

*
*   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/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Stata 12: wish list

nshephard
Administrator
On Tue, Nov 2, 2010 at 12:23 PM, Sridhar Telidevara
<[hidden email]> wrote:

> The dual objectives of any  software like stata are to assist
>
> 1. Research, and
>
> 2. Presentation of the results obtained from the research.
>
>
> I believe that the former is more difficult to design that suits
> everybody's requirements. This is where I am flexible and I am full of
> praise for stata modules and user programs.  However the latter is
> easier and that is where lot of standardization can be made so that
> researchers do not have to spend their time breaking their heads
> figuring out how to insert mean in a box plot etc. I am sure most of
> you would agree with me on this. I understand that not everything can
> be perfected but we can push the horizons. Flexibility and
> standardization are both important  for researchers.

You don't define what you mean by "standardisation".  The problem is
that what is "standard" for you is different from my "standard" and
the next persons "standard".

As I wrote, I use LaTeX, others prefer Word-processors, others may
prefer HTML.  Which should take precedence?  Why should the others be
neglected for not being the right "standard"?

The aspect of presentation that is worth developing in Stata, and
indeed has come along leaps and bounds since it underwent a major
revision, is the graphics engine.  Nick Cox covered the specific
request for mean/mode/median on box-plots quite comprehensively.

Neil

--
"Our civilization would be pitifully immature without the intellectual
revolution led by Darwin" - Motoo Kimura, The Neutral Theory of
Molecular Evolution

Email - [hidden email]
Website - http://kimura-no-ip.org/
Photos - http://www.flickr.com/photos/slackline/

*
*   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/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Stata 12: wish list

cmagazzino
In reply to this post by Robert A Yaffee
Dear Robert,
a lot of papers refer to linear and non linear Granger-causality test. A
very simple research on Google might show this. As an example, look at
this link, among the others:

http://www.jstor.org/pss/2329266

Another problem that I have with Stata is how perform a causality test
after a VCEM instead of a VAR.
As regard to panel, Stata is very powerful, but actually we can't have a
clear routine on DOLS, FMOLS and Canonical Cointegrating Regressions.
Finally, I think that Stata doesn't perform Toda and Yamamoto causality test.

Thanks a lot in advance for Your suggestions and advices!

--
COSIMO MAGAZZINO
DIPES
School of Political Sciences
Roma Tre University
Via G. Chiabrera 199, 00145, RM
tel.: +39 0657335347
fax: +39 0657335282

*
*   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/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Stata 12: wish list

Maarten buis
In reply to this post by Sridhar Telidevara
--- On Tue, 2/11/10, Sridhar Telidevara wrote:

> The dual objectives of any software like stata are to assist
>
> 1. Research, and
>
> 2. Presentation of the results obtained from the research.
>
> I believe that the former is more difficult to design that
> suits everybody's requirements. <snip>  However, the latter
> is easier and that is where lot of standardization can be
> made so that researchers do not have to spend their time
> breaking their heads figuring out how to insert mean in a
> box plot etc.

That is actually an excelent example of why the latter is
less open to standardization. I would say that adding a mean
to a box plot is alien to the basic idea behind the box plot,
which means that my standard would be not to include the mean
in that plot. To quote Nick: "the great thing about standards
is that there are so many to choose from".

The problem that needs to be solved is that the presentation
of results is influenced by the research question one wants
to answer, the analysis one performed, the tradition in each
specific sub-sub-discipline/journal, and ultimately taste.
So I am sure there will be many complaints about the
complexity of the syntax/menu when Stata comes up with a new
output system. That is the price we will have to pay in order
to be able to use the "standard" display of our choice.

-- Maarten

--------------------------
Maarten L. Buis
Institut fuer Soziologie
Universitaet Tuebingen
Wilhelmstrasse 36
72074 Tuebingen
Germany

http://www.maartenbuis.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/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Stata 12: wish list

Nick Cox
In reply to this post by Thomas Speidel
I think that is a good summary of a widely held view. I have no axe to grind here as I am not a provider in the main territory that Thomas has in mind, but on behalf of fellow user-programmers I suggest that the descriptor "ad hoc" does not quite fit the situation.

Of the programs implied here, and that I know about, I'd say that they all have a clear vision of what they want to do which has been maintained throughout their development. It can seem ad hoc if you want to do something else, but that is a different matter. As I've already remarked in this thread, user-programmers tend to write programs for themselves, with no guarantee of meeting anyone else's needs.

The overall problem here is describable in two words "better tables" and lots of users want to second that. But some want more unified syntax for tables within Stata, some want more detailed control, some want greater support for export to their own favourite foreign programs, standard or otherwise, and some want two or three of those. All understandable enough, but don't complain if this all turns into a [T] manual several hundred pages long to meet not only your reasonable requests, but most other people's too!

Emphasis here varies depending on where you come from. Some people seem routinely to be producing tens or hundreds of tables in rigid formats full of coefficients, standard errors and P-values and those awful stars. Do people actually read them too?

Nick
[hidden email]

P.S. On a key question of intellectual priority, I lay claim to "Some Alternative Software", as indeed could anyone else who came up with it earlier or later.  But (with thanks to Maarten for the compliment) the joke about there being so many standards to choose from is certainly not mine. Andrew Tanenbaum got there much earlier.

Thomas Speidel

While I understand the intricacies of such a task, for me too this has  
been on the wish list for some time.  Judging from the number of  
user-written programs, the presentations at user group meetings and  
conferences and how Some Alternative Sofwtare (don't remember who came  
up with this acronym) fares in this area, I suspect the folks at Stata  
are taking notice.  I am not sure how far up this topic is in the  
priority list.

One common response I hear is that solutions exists in the form of  
user written programs.  There is a large number of great work (Ian  
Watson, John Gallup, Michael Lokshin, Ben Jann, Roger Newson to name a  
few authors).  But these tend to be ad-hoc solutions:  some only  
handle a certain type of data, some will display p-values but no  
confidence intervals, etc etc. This in my view has the side effect of  
forcing the user to either write his or her program, or produce the  
tables from scratch in Excel/OpenOffice/Latex.

Making more estimates available after estimation and more results  
stored in locals in general could perhaps be a good starting point.  
Eventually, I would love to see more automation in this area from Stata.

Richard Ohrvall

> I do not know if requests for features in the coming version of Stata
> is of any use, but since it seems as if the Stata people are reading
> this list and they seem like nice people, I take my chance.
>
> I would really like a better support for creating tables in the next
> version of Stata. By this I mean an output of tables that is easily
> imported into Word or any other word processor. I would also like to
> see a bit more flexibility in the table commands. To me it is a bit
> surprising that you e.g. can't control the number of decimals in the
> output of -tab-. This is very annoying when you want to see a
> proportion with a specific number of decimals. All other major
> statistical programs seem to be ahead of Stata in these aspects. Yes,
> I know that there are user-written programs that do these things, but
> these seem like basic functions that should be included in the
> program. One solution could be an optional output window (like the
> graph window), so that those who want to keep the present design and
> output could do so.
>

*
*   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/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Re: Stata 12: wish list

Amy Dunbar
In reply to this post by nshephard
Looking at it from capturing share of the market, it may make sense "standardize" table output.  I spent the better part of a weekend trying to figure out how to output tables, and yes, now I know how to do it, but many users aren't willing to put that time in. If another product provides a more intuitive way to create table output, the other product may be more attractive. (OK, maybe not; I love Stata.)  I get the impression that the Latex users are daily users of Stata, so they can probably figure out just about anything.  Someone like me has to struggle understanding the Stata commands.  For example, it was nonintuitive to me that some output required -estpost- and some required -eststo-.  Undoubtedly some of you are thinking that is obvious, but I may be representative of a lot of Stata users.  

I am providing my code below simply to show how "nonintuitive" this code is to an occasional user; now imagine that user having to come up with this code.  I have no doubt that my code can be improved, but I sweat bullets over this code.  I received a lot of helpful comments from statalist users, so thank you once again!  And thank goodness for this link, http://repec.org/bocode/e/estout/index.html.

********************************
*TABLE 3 and 3matrixfull - Correlations*
********************************

egen rETR1 = rank (GAAP_ETR)
egen rETR2 = rank (CURR_ETR)
egen rETR3 = rank (CASH_ETR)
egen rETR4 = rank (LR_CASH_ETR)
egen rBTD  = rank (w_totalBTD)
egen rpBTD = rank (w_permBTD)
egen rDTAX = rank (w_DTAX)
egen raBTD = rank (w_abnBTD)
egen rSHELTER = rank (w_SHELTER)

estpost correlate GAAP_ETR CURR_ETR CASH_ETR LR_CASH_ETR w_totalBTD w_permBTD w_DTAX w_abnBTD w_SHELTER, matrix quietly

esttab . using "table3.rtf", replace notype unstack compress noobs nogaps nostar ///
      title({\b Table 3, Panel A:} {\i Unadjusted Correlations}) ///
          label varwidth(8) modelwidth(7) ///
          nonotes nonumbers ///
          addnote("Pearson (Spearman) correlation coefficents are reported below (above) the diagonal. See Table 1 for variable definitions.")

*thanks to Nick, I figured out how to output a correlation table that had spearman, but I still have to do a cut and paste to get the final table.  
* Output full matrix to enable easy cut and paste into upper half of pwcorr correlation matrix.

estpost correlate rETR1 rETR2 rETR3 rETR4 rBTD rpBTD rDTAX raBTD rSHELTER, matrix nohalf quietly

esttab . using "table3matrixfull.rtf", replace notype unstack compress noobs nogaps nostar ///
      title({\b Table 3, Panel B:} {\i Unadjusted Spearman Rank Correlations}) ///
          varwidth(8) modelwidth(7) ///
          nonotes nonumbers ///
          addnote("See Table 1 for variable definitions.")

 ********************************
*TABLE 4 - Summary Stats*
********************************
estpost tabstat `xlist', stat(n mean sd p25 med p75) columns(statistics)  

esttab . using "table4.rtf", replace cells("mean(fmt(%9.4f)) sd p25 p50 p75") noobs nogaps ///
      title({\b Table 4, Panel A:} {\i Descriptive Statistics}) ///
          label varwidth(10) modelwidth(10) ///
          addnote("See Table 1 for variable definitions.")

********************************
*TABLE 6 - Regression Output*
********************************
eststo clear
eststo ETR1: quietly ivreg2 GAAP_ETR medGAAP_ETR lagGAAP_ETR, robust cluster(gvkey fyear)

esttab using "table6.rtf",replace se ar2 unstack nogaps compress nonumbers ///
  title({\b Table 6} {\line}{\pard \qc Multivariate Regressions \par}) ///
  label varwidth(14) modelwidth(8) ///
  stat(N r2_a, labels("N" "Adj. R2")) ///
  addnote("See Table 1 for variable definitions.")


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of nshephard
Sent: Tuesday, November 02, 2010 5:35 AM
To: [hidden email]
Subject: st: Re: Stata 12: wish list


Thomas Speidel wrote:

>
> One common response I hear is that solutions exists in the form of
> user written programs.  There is a large number of great work (Ian
> Watson, John Gallup, Michael Lokshin, Ben Jann, Roger Newson to name a
> few authors).  But these tend to be ad-hoc solutions:  some only
> handle a certain type of data, some will display p-values but no
> confidence intervals, etc etc. This in my view has the side effect of
> forcing the user to either write his or her program, or produce the
> tables from scratch in Excel/OpenOffice/Latex.
>

The problem with this though is that there is no way of anticipating what an individual will think is most appropriate.  Personally I'd plump for LaTeX, but I'm sure others wouldn't.  There will always be something that one person uses that isn't supported and "should be".

The user-written commands are very flexible and exceptionally useful and I'm very grateful to the various authors for developing them in the first instance, sharing them and continuing to develop them.

Having to write your own program to produce the desired table is not a bad thing, and after you've done it once you'll find you can re-use your code.
It may even evolve into a ado-file that you can then share with the rest of the world.

This is a good thing to my mind.

Personally I would rather see Stata development focus on statistical issues than presentation issues as they are far more common to all users.


Thomas Speidel wrote:
>
> Making more estimates available after estimation and more results  
> stored in locals in general could perhaps be a good starting point.  
>

Most commands leave behind a lot of results in scalars and matrices that can be utilised afterwards.  See -man return- for full details.  I rarely find there is anything lacking from these.

Neil

--
View this message in context: http://statalist.1588530.n2.nabble.com/Stata-12-wish-list-tp5695005p5696398.html
Sent from the Statalist mailing list archive at Nabble.com.
*
*   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/

*
*   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/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Re: Stata 12: wish list

nshephard
Administrator
The mild irony being that -estout- et al. aren't official commands,
but are written by Ben Jann and support LaTex, HTML, tab-delimited and
fixed-width output.

Just as much as you have a limited amount of time and resources to put
into learning how to use Stata and achieve _exactly_ what you want,
the same is true of StataCorp developers, they can implement
everyone's wishes ("You can please some of the people some of the
time, but you can't please all the people all of the time").  The
desire to have better "standardised" table output crops up regularly
and so far most development on this front has come from users rather
than StataCorp.

Neil

--
"Our civilization would be pitifully immature without the intellectual
revolution led by Darwin" - Motoo Kimura, The Neutral Theory of
Molecular Evolution

Email - [hidden email]
Website - http://kimura-no-ip.org/
Photos - http://www.flickr.com/photos/slackline/
*
*   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/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: RE: Re: Stata 12: wish list

Nick Cox
In reply to this post by Amy Dunbar
I see main three points arising here.

1. None of this is trivially easy, even if what you want is provided in the software and well documented.

2. Whatever StataCorp do, it's not going to get much easier, unless exceptionally their defaults on everything happen to match exactly your choices. Whatever StataCorp do, the consequence is going to be lots of handles to tweak, and mastering that won't be trivial either. I am still getting to grips with Stata graphics, which I have used just about every working day for almost 20 years. Tables, or reporting, is about the same size of beast.

3. What I see here is positive: You care about well-designed tables and put a lot of work into this code. Next time, not everything will be different and you can steal from what you learned.

On a detail: if ranking lots of variables, watch out for missing values. Safer code looks like this:

gen touse = !missing(a, b, c)

foreach v of var a b c {
        egen rank_`v' = rank(`v') if touse
}

That way, missing values are excluded systematically across a varlist.

Nick
[hidden email]

Amy Dunbar

Looking at it from capturing share of the market, it may make sense "standardize" table output.  I spent the better part of a weekend trying to figure out how to output tables, and yes, now I know how to do it, but many users aren't willing to put that time in. If another product provides a more intuitive way to create table output, the other product may be more attractive. (OK, maybe not; I love Stata.)  I get the impression that the Latex users are daily users of Stata, so they can probably figure out just about anything.  Someone like me has to struggle understanding the Stata commands.  For example, it was nonintuitive to me that some output required -estpost- and some required -eststo-.  Undoubtedly some of you are thinking that is obvious, but I may be representative of a lot of Stata users.  

I am providing my code below simply to show how "nonintuitive" this code is to an occasional user; now imagine that user having to come up with this code.  I have no doubt that my code can be improved, but I sweat bullets over this code.  I received a lot of helpful comments from statalist users, so thank you once again!  And thank goodness for this link, http://repec.org/bocode/e/estout/index.html.

********************************
*TABLE 3 and 3matrixfull - Correlations*
********************************

egen rETR1 = rank (GAAP_ETR)
egen rETR2 = rank (CURR_ETR)
egen rETR3 = rank (CASH_ETR)
egen rETR4 = rank (LR_CASH_ETR)
egen rBTD  = rank (w_totalBTD)
egen rpBTD = rank (w_permBTD)
egen rDTAX = rank (w_DTAX)
egen raBTD = rank (w_abnBTD)
egen rSHELTER = rank (w_SHELTER)

estpost correlate GAAP_ETR CURR_ETR CASH_ETR LR_CASH_ETR w_totalBTD w_permBTD w_DTAX w_abnBTD w_SHELTER, matrix quietly

esttab . using "table3.rtf", replace notype unstack compress noobs nogaps nostar ///
      title({\b Table 3, Panel A:} {\i Unadjusted Correlations}) ///
          label varwidth(8) modelwidth(7) ///
          nonotes nonumbers ///
          addnote("Pearson (Spearman) correlation coefficents are reported below (above) the diagonal. See Table 1 for variable definitions.")

*thanks to Nick, I figured out how to output a correlation table that had spearman, but I still have to do a cut and paste to get the final table.  
* Output full matrix to enable easy cut and paste into upper half of pwcorr correlation matrix.

estpost correlate rETR1 rETR2 rETR3 rETR4 rBTD rpBTD rDTAX raBTD rSHELTER, matrix nohalf quietly

esttab . using "table3matrixfull.rtf", replace notype unstack compress noobs nogaps nostar ///
      title({\b Table 3, Panel B:} {\i Unadjusted Spearman Rank Correlations}) ///
          varwidth(8) modelwidth(7) ///
          nonotes nonumbers ///
          addnote("See Table 1 for variable definitions.")

 ********************************
*TABLE 4 - Summary Stats*
********************************
estpost tabstat `xlist', stat(n mean sd p25 med p75) columns(statistics)  

esttab . using "table4.rtf", replace cells("mean(fmt(%9.4f)) sd p25 p50 p75") noobs nogaps ///
      title({\b Table 4, Panel A:} {\i Descriptive Statistics}) ///
          label varwidth(10) modelwidth(10) ///
          addnote("See Table 1 for variable definitions.")

********************************
*TABLE 6 - Regression Output*
********************************
eststo clear
eststo ETR1: quietly ivreg2 GAAP_ETR medGAAP_ETR lagGAAP_ETR, robust cluster(gvkey fyear)

esttab using "table6.rtf",replace se ar2 unstack nogaps compress nonumbers ///
  title({\b Table 6} {\line}{\pard \qc Multivariate Regressions \par}) ///
  label varwidth(14) modelwidth(8) ///
  stat(N r2_a, labels("N" "Adj. R2")) ///
  addnote("See Table 1 for variable definitions.")


*
*   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/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Stata 12: wish list

Robert A Yaffee
In reply to this post by cmagazzino
Cosimo,
   I would not think that volume is a good proxy for
volatility.  They seem to me very different, although
there may be a relationship between them.
   Granger causality tests linear relationships for precedence.
   If you want to test for nonlinear relationships, there are many
functional forms to examine before you can say that there is no nonlinear
relationship.  Granger causality has generally been applied in
bivariate examples.
   But you might try to apply this to multiple causality by adding
additional variables to the tests.  Do you know that you
have all relevant factors in their proper functional forms included?
Moreover, there may be a nonlinear or linear relationship on a sampling
frequency that you have not tested. How do you know that there is
not some indirect relationship but not a direct relationship?  Do
you know that you have tested all of the lags necessary to assure
no long run as well as short run precedence?
   I presume that these limitations are why the topic is
called Weiner-Granger causality.
   Regards,
       Robert

Robert A. Yaffee, Ph.D.
Research Professor
Silver School of Social Work
New York University

Biosketch: http://homepages.nyu.edu/~ray1/Biosketch2009.pdf

CV:  http://homepages.nyu.edu/~ray1/vita.pdf

----- Original Message -----
From: [hidden email]
Date: Tuesday, November 2, 2010 8:42 am
Subject: Re: st: Stata 12: wish list
To: [hidden email]
Cc: [hidden email]


> Dear Robert,
> a lot of papers refer to linear and non linear Granger-causality test.
> A
> very simple research on Google might show this. As an example, look at
> this link, among the others:
>
> http://www.jstor.org/pss/2329266
>
> Another problem that I have with Stata is how perform a causality test
> after a VCEM instead of a VAR.
> As regard to panel, Stata is very powerful, but actually we can't have
> a
> clear routine on DOLS, FMOLS and Canonical Cointegrating Regressions.
> Finally, I think that Stata doesn't perform Toda and Yamamoto
> causality test.
>
> Thanks a lot in advance for Your suggestions and advices!
>
> --
> COSIMO MAGAZZINO
> DIPES
> School of Political Sciences
> Roma Tre University
> Via G. Chiabrera 199, 00145, RM
> tel.: +39 0657335347
> fax: +39 0657335282
>
> *
> *   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/
*
*   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/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: RE: RE: Re: Stata 12: wish list

Amy Dunbar
In reply to this post by Nick Cox
Thanks for the ranking code, Nick.  I frequently forget that missing vars are still included as the largest.  And now I finally understand the "touse" code that I have seen so frequently in sample code.  Awesome!

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Nick Cox
Sent: Tuesday, November 02, 2010 10:04 AM
To: '[hidden email]'
Subject: st: RE: RE: Re: Stata 12: wish list

I see main three points arising here.

1. None of this is trivially easy, even if what you want is provided in the software and well documented.

2. Whatever StataCorp do, it's not going to get much easier, unless exceptionally their defaults on everything happen to match exactly your choices. Whatever StataCorp do, the consequence is going to be lots of handles to tweak, and mastering that won't be trivial either. I am still getting to grips with Stata graphics, which I have used just about every working day for almost 20 years. Tables, or reporting, is about the same size of beast.

3. What I see here is positive: You care about well-designed tables and put a lot of work into this code. Next time, not everything will be different and you can steal from what you learned.

On a detail: if ranking lots of variables, watch out for missing values. Safer code looks like this:

gen touse = !missing(a, b, c)

foreach v of var a b c {
        egen rank_`v' = rank(`v') if touse
}

That way, missing values are excluded systematically across a varlist.

Nick
[hidden email]

Amy Dunbar

Looking at it from capturing share of the market, it may make sense "standardize" table output.  I spent the better part of a weekend trying to figure out how to output tables, and yes, now I know how to do it, but many users aren't willing to put that time in. If another product provides a more intuitive way to create table output, the other product may be more attractive. (OK, maybe not; I love Stata.)  I get the impression that the Latex users are daily users of Stata, so they can probably figure out just about anything.  Someone like me has to struggle understanding the Stata commands.  For example, it was nonintuitive to me that some output required -estpost- and some required -eststo-.  Undoubtedly some of you are thinking that is obvious, but I may be representative of a lot of Stata users.  

I am providing my code below simply to show how "nonintuitive" this code is to an occasional user; now imagine that user having to come up with this code.  I have no doubt that my code can be improved, but I sweat bullets over this code.  I received a lot of helpful comments from statalist users, so thank you once again!  And thank goodness for this link, http://repec.org/bocode/e/estout/index.html.

********************************
*TABLE 3 and 3matrixfull - Correlations*
********************************

egen rETR1 = rank (GAAP_ETR)
egen rETR2 = rank (CURR_ETR)
egen rETR3 = rank (CASH_ETR)
egen rETR4 = rank (LR_CASH_ETR)
egen rBTD  = rank (w_totalBTD)
egen rpBTD = rank (w_permBTD)
egen rDTAX = rank (w_DTAX)
egen raBTD = rank (w_abnBTD)
egen rSHELTER = rank (w_SHELTER)

estpost correlate GAAP_ETR CURR_ETR CASH_ETR LR_CASH_ETR w_totalBTD w_permBTD w_DTAX w_abnBTD w_SHELTER, matrix quietly

esttab . using "table3.rtf", replace notype unstack compress noobs nogaps nostar ///
      title({\b Table 3, Panel A:} {\i Unadjusted Correlations}) ///
          label varwidth(8) modelwidth(7) ///
          nonotes nonumbers ///
          addnote("Pearson (Spearman) correlation coefficents are reported below (above) the diagonal. See Table 1 for variable definitions.")

*thanks to Nick, I figured out how to output a correlation table that had spearman, but I still have to do a cut and paste to get the final table.  
* Output full matrix to enable easy cut and paste into upper half of pwcorr correlation matrix.

estpost correlate rETR1 rETR2 rETR3 rETR4 rBTD rpBTD rDTAX raBTD rSHELTER, matrix nohalf quietly

esttab . using "table3matrixfull.rtf", replace notype unstack compress noobs nogaps nostar ///
      title({\b Table 3, Panel B:} {\i Unadjusted Spearman Rank Correlations}) ///
          varwidth(8) modelwidth(7) ///
          nonotes nonumbers ///
          addnote("See Table 1 for variable definitions.")

 ********************************
*TABLE 4 - Summary Stats*
********************************
estpost tabstat `xlist', stat(n mean sd p25 med p75) columns(statistics)  

esttab . using "table4.rtf", replace cells("mean(fmt(%9.4f)) sd p25 p50 p75") noobs nogaps ///
      title({\b Table 4, Panel A:} {\i Descriptive Statistics}) ///
          label varwidth(10) modelwidth(10) ///
          addnote("See Table 1 for variable definitions.")

********************************
*TABLE 6 - Regression Output*
********************************
eststo clear
eststo ETR1: quietly ivreg2 GAAP_ETR medGAAP_ETR lagGAAP_ETR, robust cluster(gvkey fyear)

esttab using "table6.rtf",replace se ar2 unstack nogaps compress nonumbers ///
  title({\b Table 6} {\line}{\pard \qc Multivariate Regressions \par}) ///
  label varwidth(14) modelwidth(8) ///
  stat(N r2_a, labels("N" "Adj. R2")) ///
  addnote("See Table 1 for variable definitions.")


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

*
*   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/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Stata 12: wish list

Robert A Yaffee
In reply to this post by Robert A Yaffee
Cosimo,
   I think you are correct in that the Toda-Yamamoto version of the Granger
causality test would be a useful addition to Stata.
  - Robert
 

Robert A. Yaffee, Ph.D.
Research Professor
Silver School of Social Work
New York University

Biosketch: http://homepages.nyu.edu/~ray1/Biosketch2009.pdf

CV:  http://homepages.nyu.edu/~ray1/vita.pdf

----- Original Message -----
From: Robert A Yaffee <[hidden email]>
Date: Tuesday, November 2, 2010 11:37 am
Subject: Re: st: Stata 12: wish list
To: [hidden email]


> Cosimo,
>    I would not think that volume is a good proxy for
> volatility.  They seem to me very different, although
> there may be a relationship between them.
>    Granger causality tests linear relationships for precedence.
>    If you want to test for nonlinear relationships, there are many
> functional forms to examine before you can say that there is no
> nonlinear
> relationship.  Granger causality has generally been applied in
> bivariate examples.
>    But you might try to apply this to multiple causality by adding
> additional variables to the tests.  Do you know that you
> have all relevant factors in their proper functional forms included?
> Moreover, there may be a nonlinear or linear relationship on a
> sampling
> frequency that you have not tested. How do you know that there is
> not some indirect relationship but not a direct relationship?  Do
> you know that you have tested all of the lags necessary to assure
> no long run as well as short run precedence?
>    I presume that these limitations are why the topic is
> called Weiner-Granger causality.
>    Regards,
>        Robert
>
> Robert A. Yaffee, Ph.D.
> Research Professor
> Silver School of Social Work
> New York University
>
> Biosketch: http://homepages.nyu.edu/~ray1/Biosketch2009.pdf
>
> CV:  http://homepages.nyu.edu/~ray1/vita.pdf
>
> ----- Original Message -----
> From: [hidden email]
> Date: Tuesday, November 2, 2010 8:42 am
> Subject: Re: st: Stata 12: wish list
> To: [hidden email]
> Cc: [hidden email]
>
>
> > Dear Robert,
> > a lot of papers refer to linear and non linear Granger-causality
> test.
> > A
> > very simple research on Google might show this. As an example, look
> at
> > this link, among the others:
> >
> > http://www.jstor.org/pss/2329266
> >
> > Another problem that I have with Stata is how perform a causality test
> > after a VCEM instead of a VAR.
> > As regard to panel, Stata is very powerful, but actually we can't
> have
> > a
> > clear routine on DOLS, FMOLS and Canonical Cointegrating Regressions.
> > Finally, I think that Stata doesn't perform Toda and Yamamoto
> > causality test.
> >
> > Thanks a lot in advance for Your suggestions and advices!
> >
> > --
> > COSIMO MAGAZZINO
> > DIPES
> > School of Political Sciences
> > Roma Tre University
> > Via G. Chiabrera 199, 00145, RM
> > tel.: +39 0657335347
> > fax: +39 0657335282
> >
> > *
> > *   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/
> *
> *   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/
*
*   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/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Stata 12: wish list

Thomas Speidel
In reply to this post by Nick Cox
Thanks Nick for your input on this topic.  I agree it is a very comlex  
problem with different expectations from different users.  
Nonetheless, when I look at graphs in Stata, there is hardly anything  
I don't like, enough possibilities to please anyone, and in my mind  
there is virtually no limit to the kind of graph one can produce.

One day I would love to see the same thick manual for tables (and I  
promise I will not complain).  I can alreay visualize one example:
[T] table export -- Export current table
                    implied
         suffix     option         output format
         ---------------------------------------------------------------------
         .tex       as(tex)        LaTeX
         .rtf       as(rtf)        RTF (Rich Text Format)
         .xml       as(xml)        Extensible Markup Language
         .pdf       as(pdf)        PDF
         .epf       as(epf)        an Evil Proprietary Format :-)
         ---------------------------------------------------------------------

P.S. Not to discriminate against other leading software, we need an  
acronym for SPSS too!

--
Thomas Speidel

Quoting Nick Cox <[hidden email]> Tue  2 Nov 07:31:58 2010:

> I think that is a good summary of a widely held view. I have no axe  
> to grind here as I am not a provider in the main territory that  
> Thomas has in mind, but on behalf of fellow user-programmers I  
> suggest that the descriptor "ad hoc" does not quite fit the situation.
>
> Of the programs implied here, and that I know about, I'd say that  
> they all have a clear vision of what they want to do which has been  
> maintained throughout their development. It can seem ad hoc if you  
> want to do something else, but that is a different matter. As I've  
> already remarked in this thread, user-programmers tend to write  
> programs for themselves, with no guarantee of meeting anyone else's  
> needs.
>
> The overall problem here is describable in two words "better tables"  
> and lots of users want to second that. But some want more unified  
> syntax for tables within Stata, some want more detailed control,  
> some want greater support for export to their own favourite foreign  
> programs, standard or otherwise, and some want two or three of  
> those. All understandable enough, but don't complain if this all  
> turns into a [T] manual several hundred pages long to meet not only  
> your reasonable requests, but most other people's too!
>
> Emphasis here varies depending on where you come from. Some people  
> seem routinely to be producing tens or hundreds of tables in rigid  
> formats full of coefficients, standard errors and P-values and those  
> awful stars. Do people actually read them too?
>
> Nick
> [hidden email]
>
> P.S. On a key question of intellectual priority, I lay claim to  
> "Some Alternative Software", as indeed could anyone else who came up  
> with it earlier or later.  But (with thanks to Maarten for the  
> compliment) the joke about there being so many standards to choose  
> from is certainly not mine. Andrew Tanenbaum got there much earlier.
>
> Thomas Speidel
>
> While I understand the intricacies of such a task, for me too this has
> been on the wish list for some time.  Judging from the number of
> user-written programs, the presentations at user group meetings and
> conferences and how Some Alternative Sofwtare (don't remember who came
> up with this acronym) fares in this area, I suspect the folks at Stata
> are taking notice.  I am not sure how far up this topic is in the
> priority list.
>
> One common response I hear is that solutions exists in the form of
> user written programs.  There is a large number of great work (Ian
> Watson, John Gallup, Michael Lokshin, Ben Jann, Roger Newson to name a
> few authors).  But these tend to be ad-hoc solutions:  some only
> handle a certain type of data, some will display p-values but no
> confidence intervals, etc etc. This in my view has the side effect of
> forcing the user to either write his or her program, or produce the
> tables from scratch in Excel/OpenOffice/Latex.
>
> Making more estimates available after estimation and more results
> stored in locals in general could perhaps be a good starting point.
> Eventually, I would love to see more automation in this area from Stata.
>
> Richard Ohrvall
>
>> I do not know if requests for features in the coming version of Stata
>> is of any use, but since it seems as if the Stata people are reading
>> this list and they seem like nice people, I take my chance.
>>
>> I would really like a better support for creating tables in the next
>> version of Stata. By this I mean an output of tables that is easily
>> imported into Word or any other word processor. I would also like to
>> see a bit more flexibility in the table commands. To me it is a bit
>> surprising that you e.g. can't control the number of decimals in the
>> output of -tab-. This is very annoying when you want to see a
>> proportion with a specific number of decimals. All other major
>> statistical programs seem to be ahead of Stata in these aspects. Yes,
>> I know that there are user-written programs that do these things, but
>> these seem like basic functions that should be included in the
>> program. One solution could be an optional output window (like the
>> graph window), so that those who want to keep the present design and
>> output could do so.
>>
>
> *
> *   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/
>



--
Thomas Speidel


*
*   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/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: RE: RE: RE: Re: Stata 12: wish list

Nick Cox
In reply to this post by Amy Dunbar
What you may have seen is something like

marksample touse

... if `touse'

This is similar in spirit but not identical:

1. -marksample- automatically marks observations as 1 or 0, to use or not to use, those values being put in a temporary variable, conventionally `touse', that takes account of any prior -if-, -in-, weights and missings consistently with a previous -syntax- statement.

2. The example with a -touse- variable was just my own code and is not as versatile. You'd also need to take account of any -if- or -in- restrictions and zero weights.

Nick
[hidden email]

Amy Dunbar

Thanks for the ranking code, Nick.  I frequently forget that missing vars are still included as the largest.  And now I finally understand the "touse" code that I have seen so frequently in sample code.  Awesome!

Nick Cox

I see main three points arising here.

1. None of this is trivially easy, even if what you want is provided in the software and well documented.

2. Whatever StataCorp do, it's not going to get much easier, unless exceptionally their defaults on everything happen to match exactly your choices. Whatever StataCorp do, the consequence is going to be lots of handles to tweak, and mastering that won't be trivial either. I am still getting to grips with Stata graphics, which I have used just about every working day for almost 20 years. Tables, or reporting, is about the same size of beast.

3. What I see here is positive: You care about well-designed tables and put a lot of work into this code. Next time, not everything will be different and you can steal from what you learned.

On a detail: if ranking lots of variables, watch out for missing values. Safer code looks like this:

gen touse = !missing(a, b, c)

foreach v of var a b c {
        egen rank_`v' = rank(`v') if touse
}

That way, missing values are excluded systematically across a varlist.


*
*   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/
12
Loading...