
12

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


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
userwritten 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 adhoc solutions: some only
handle a certain type of data, some will display pvalues 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 userwritten 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/

Administrator

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 adhoc solutions: some only
handle a certain type of data, some will display pvalues 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 userwritten 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 reuse your code. It may even evolve into a adofile 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


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 uptodate userwritten program specifically designed to draw box plots. hbox from SSC meets the second part of the prescription, but it's way outofdate 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. Userprogrammers 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 userwritten programs to add means to box plots. You can do it yourself with a few lines of Stata, as was explained in
SJ93 gr0039 . . . . . . . . Speaking Stata: Creating and varying box plots
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . N. J. Cox
Q3/09 SJ 9(3):478496 (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/


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

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 Wordprocessors, 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 boxplots 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://kimuranoip.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/


Dear Robert,
a lot of papers refer to linear and non linear Grangercausality 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/2329266Another 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/


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


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 userprogrammers 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, userprogrammers 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 Pvalues 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
userwritten 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 adhoc solutions: some only
handle a certain type of data, some will display pvalues 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 userwritten 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/


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 adhoc solutions: some only
> handle a certain type of data, some will display pvalues 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 userwritten 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 reuse your code.
It may even evolve into a adofile 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/Stata12wishlisttp5695005p5696398.htmlSent 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/

Administrator

The mild irony being that estout et al. aren't official commands,
but are written by Ben Jann and support LaTex, HTML, tabdelimited and
fixedwidth 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://kimuranoip.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/


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


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 WeinerGranger 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.pdfCV: 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 Grangercausality 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/


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


Cosimo,
I think you are correct in that the TodaYamamoto 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.pdfCV: 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 WeinerGranger 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 Grangercausality
> 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/


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 userprogrammers 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, userprogrammers 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 Pvalues 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
> userwritten 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 adhoc solutions: some only
> handle a certain type of data, some will display pvalues 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 userwritten 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/


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