Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Marcos Almeida
    replied
    High density (>= 300 dpi) "for publishing" customized tiff or jpeg graphs. Nowadays I need to save as jpeg, then import in a different sotware so as to convert it to high densitiy graph.

    Leave a comment:


  • Sonnen Blume
    replied
    A friendlier version of sem. Currently its almost useless as it takes too long and returns many errors for the same data that Mplus caters in a blink.
    AND, better description of the errors. Stata errors messages are usually very general and leaves no way to know where things have gone wrong, unlike those in R and Mplus.

    Leave a comment:


  • Niels Henrik Bruun
    replied
    Yes, but you can't reuse the extracted from -list-. Sorry for being imprecise
    Last edited by Niels Henrik Bruun; 22 Jan 2020, 06:35. Reason: Bad english

    Leave a comment:


  • Nick Cox
    replied
    I don’t follow all of #99. For example, list certainly supports selection of variables and if and in.

    Leave a comment:


  • Niels Henrik Bruun
    replied
    #98 on.
    Nick Cox Maybe you are satisfied with -list- and -summarize-.
    But I am not.

    -list- would be a much better tool if one could subselect variables and (unique) rows by if and in.
    And it would very nice if what I extracted with one command could be reused immediately without figuring out how to save it for reuse using af different command.

    And likewise for -summarize- : Why is it that is worth printing means etc in the log using -summarize-.
    Most of the times I have to report the found results somewhere else afterwards.

    Leave a comment:


  • Nick Cox
    replied
    #93 on. I thought that counter-examples were obvious but here we go. If I see results of list I really don't want Stata to store those, as they are (with small exceptions) stored already as data. If I fire up display I don't expect the result to be stored either (I can arrange for that directly).

    If I quickly fire up summarize for several variables, I don't want results for them all to be saved, as that too can be arranged otherwise.

    Otherwise specific examples are helpful here, and let's hope that oversights get corrected.

    Leave a comment:


  • Niels Henrik Bruun
    replied
    I so agree with #93. The basic priciple should always be: If it is worth showing in the log, it is worth reusing (returned in r and/or e as eg matrices). Log output and reuse should be one-to-one.
    I also agree with #94 in that the reuse principle should not be limited to microsoft products.
    It is far better to split reusing into "returned for further use in frames like estimates and matrices" and exporting these frames easily as said in 96.
    Export should be quick and dirty with the possibility of going into details. Splitting "export to excel" into two commands without a Q&D is annoying.

    Examples of where this not happening is eg 1) tab2 where cell information isn't returned 2) -summarize- over several variables where only information on the last variable is returned.

    I do also think that returned information may returned in a redundant ways as eg r(table) and e(b) are returned from regression.
    There can several quite different needs.

    Leave a comment:


  • William Lisowski
    replied
    #94 Regarding "stuff that goes in the Results window that really should not be stored" I can only think of the horizontal and vertical lines used in formatting tables.

    I agree with the general principal in #93, which put another way is that, for a fairly broad definition of what constitutes "results", the generation of results and the presentation of results should be separate issues, and all presented results should be available for other purposes through mechanisms more congenial than copy-and-paste.

    Stata had what I think was a brilliant insight when it chose to split out postestimation commands that build on retained estimation results. The principle expressed in #93 is an extension of that logic, motivated perhaps by the problems of presentation but really based in a broader principle of trying to limit as little as possible subsequent use of the results for whatever purpose the user has.

    Leave a comment:


  • Rene Macon
    replied
    #94 I have currently three examples, where I think certain results should be stored, first because I would need an access and secondly, because there are other tests, where these type of results are stored.

    First example is the "dfuller" test, where I found no stored value for the estimated "drift" paramter and the standard deviation of the residauls. I have described the problem here. William found fortunately an undocumented option "certify" in the source code, that solved the problem for the drift parameter. To get the standard deviation of the residuals, I had to manipulate the source code somewhat.

    Second example is the "pperron" test, where I could not find access to the critical values of the test statistic "r(Zt)". Fortunately these critical values differ only marginally from those of the "dfuller" test.

    Third example is the "dfgls" test, where I do also not find the critical values for the dfgls test statistic. I have described the problem here. Unfortunately, nobody had so far an idea how to solve my problem. I found however an older post from Nora Kaimann with regard to the same problem here. If you have an idea, that would be great...

    From an earlier study of mine, I can also remember missing stored critical values for the trace statistics of the Johansen cointegration test, where I could however modify the source code to solve the problem.

    Leave a comment:


  • Nick Cox
    replied
    #93 I can readily think of stuff that goes in the Results window that really should not be stored!

    Still, the principle of being able to access results is good. I am interested in where you think Stata misses out here in practice. Also, it is not automatic that results are (strictly) saved results; some results are in effect new data and saving or exporting them as new variables is the way to go.

    I note that many users have no interest in MS Excel or Word, but the principle translates to anything else: LaTeX, HTML, XML, etc.

    Leave a comment:


  • Rene Macon
    replied
    The general principal should be implemented "All results displayed in the Stata output window should be stored!" such that they are accessible to be transferred in Excel or Word files.

    Currently, only a subset of these results is stored (plus a set of results, which are not displayed - which should be kept).

    Motivation: The manual transfer of test results in research papers is definitely out of time! In the future more and more users will certainly want to write results like test statistics, critical values and estimated coefficients directly in files that can be easily integrated in research papers.

    Leave a comment:


  • Ben Jann
    replied
    Correction for #91: I accidentally copied a wrong graph. The first graph has been produced using size(displ^1.5), not size(displ^2).

    Leave a comment:


  • Ben Jann
    replied
    Re #75: You could misuse heatplot for that (from SSC; also requires palettes and colrspace from SSC). Here is an example in which opacity and size of markers is proportional to a variable in the data.
    Code:
    sysuse auto
    heatplot displ price weight, discrete stat(asis) scatter size(displ^2) colors(cyan, opacity(20(2)80)) p(mlc(black)) legend(off)
    Click image for larger version

Name:	g1.png
Views:	1
Size:	89.9 KB
ID:	1532097


    Options discrete stat(asis) scatter make heatplot behave like a regular scatter command (i.e. no binning or aggregation of data, use marker symbols instead of color fields).

    Option size(displ^2) makes sizes of marker symbols proportional to the square of variable displ. This is equivalent to specifying [aw=displ^2] in twoway scatter.

    Option colors(cyan, opacity(20(2)80)) specifies to use a cyan color gradient with opacity values between 20% and 80% (in steps of 2) based on the values of variable displ (if three variables are specified in heatplot, the first variable will be used for the color gradient).

    Here is a second example with a gradient from grey to magenta.
    Code:
    heatplot displ price weight, discrete stat(asis) scatter size(displ^2) colors(gs10 magenta, opacity(50) ipolate(20)) p(mlc(black)) legend(off)
    Click image for larger version

Name:	g2.png
Views:	1
Size:	110.4 KB
ID:	1532098


    The ipolate() suboption determines how the colors are interpolated; default settings are used here, but the option is quite powerfull; have a look at help colorpalette for details. You can also interpolate across more than two colors.

    Leave a comment:


  • Bruce Weaver
    replied
    Originally posted by Rich Goldstein View Post
    I have no idea what is meant by the second point in #84
    Chris was referring to the PROCESS macro written by A.F. Hayes. It is widely used by people in psychology.

    Chris, FWIW, I think you'd be better off learning how to roll your own analyses with the tools that are available to you in Stata (e.g., -sem-, -margins-, -marginsplot-). There are many examples online to guide you. E.g., here are some examples to get you started: HTH.

    PS- See also the -mediation- command by Raymond Hicks & Dustin Tingley. Perhaps it will meet your needs?

    Code:
    ssc describe mediation
    Last edited by Bruce Weaver; 13 Jan 2020, 12:04. Reason: Added the PS.

    Leave a comment:


  • George Hoffman
    replied
    daniel and Clyde - both suggestions are helpful and instructive. thank you
    george

    Leave a comment:

Working...
X