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/ 
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/ 
Hi!
I would like that Stata enhance some timeseries techniques, such as Grangercausality after a VECM, FMOLS model, nonlinear Grangercausality. 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/ 
Administrator

In reply to this post by Thomas Speidel
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. 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 
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 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/ 
In reply to this post by cmagazzino
Cosimo,
Have you seen a nonlinearGranger 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 timeseries techniques, such as > Grangercausality after a VECM, FMOLS model, nonlinear Grangercausality. > > 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/ 
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 nonlinearGranger 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 timeseries techniques, such as >> Grangercausality after a VECM, FMOLS model, nonlinear Grangercausality. >> >> 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/ 
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/ 
In reply to this post by Robert A Yaffee
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/ 
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 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/ 
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 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/ 
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 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.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/ 
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/ 
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 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/ 
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 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/ 
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 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/ 
In reply to this post by Robert A Yaffee
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.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 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/ 
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 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/ 
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 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/ 
Free forum by Nabble  Edit this page 