Announcement

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

  • Adrien Bouguen
    replied
    One in passing:
    A possibility to save bookmarks in do files

    Leave a comment:


  • John Mullahy
    replied
    After referring to an undocumented Mata function in a separate thread reply this morning, I would again urge Stata to no longer have undocumented commands/functions. Stata's staff's opinions as to what is/isn't worthy of documentation may not coincide with Stata users'. Thanks for considering.

    Leave a comment:


  • Nora Kaimann
    replied
    A STATA-interface to X-13ARIMA-SEATS the newest seasonal adjustment software developed by the US Census Bureau would be quite useful.

    Leave a comment:


  • Siqi Fan
    replied
    I hope Stata could have a button"go back to last step"

    Leave a comment:


  • Leonardo Guizzetti
    replied
    H Garret, you are correct about how I typically use Stata, and I have only offered my opinion on the matter, as you have offered yours. There is no "harm", per se, unless integration with Git were handled in some proprietary way that users of Git expect.

    Leave a comment:


  • Garret Christensen
    replied
    I see your point Leonardo, and I agree that it may not be helpful for your needs, but I don't see the harm. I'm guessing you rarely use any of the pulldown menus in either the Stata main window or the do file editor, correct? What's the harm if there were another option under the "Project" pulldown in the do file editor? RStudio, Atom, and other text editors have basic Git integrated. Of course if you want to do more specific commands you go to the shell or a Git client, but for me, 90% of the time I could add, commit, and push my .do files without opening a second program.

    Leave a comment:


  • Leonardo Guizzetti
    replied
    Re #111

    My personal take on Git with Stata is that there should be no integration of the two. I use Git personally and professionally and my go to interface is either a bash shell or dedicated Git client. My reasons for this is that my repositories nearly always contain more file types that do and log files. I also think actions more advanced than simple commits are best handled externally, especially if there are visual displays of branches and commits, or -diff- utilities. I have seen how Git integration is handled in SAS Enterprise Guide and it's a wierd proprietary version bundled with it which is not helpful for my needs.

    Leave a comment:


  • Garret Christensen
    replied
    1) I think the built-in do file editor could be improved by incorporating some simple Git version control commands.
    2) I'd like it if the command window knew how to handle all of the comment characters that work in .do files. (I think currently // and /// that are valid in .do will give errors if pasted to the command window.)

    Leave a comment:


  • Mario Ferri
    replied
    Time varying stochastic volatility, Time Varying Parameters and Time Varying Trends for single Vars and panel data .Similar to the ECB BEAR toolbox for matlab.

    Leave a comment:


  • Christopher Bratt
    replied
    My main concern would be an improved approach to reproducible research, with a flexility similar to Rmarkdown and the knitr package in R/RStudio.

    I also second the hope for much improved speed in SEM analyses.

    Leave a comment:


  • Richard Williams
    replied
    This Stata News entry describes the xtmlogit command:

    https://www.stata.com/stata-news/news29-2/xtmlogit/

    Which, alas, doesn't actually exist, but the article tells you how to use gsem instead. Example 41g in the sem manual -- "Two-level multinomial logistic regression (multilevel)" -- also discusses how to do this.

    I wish xtmlogit and memlogit really did exist -- or, if you searched for help on those commands, at least get relayed to the article and/or to the sem manual example. I've referred a couple of people to these sources, and I think they'd be more useful if they weren't hidden so much.

    Leave a comment:


  • Niels Henrik Bruun
    replied
    Clyde Schechter You are right. There are ways of getting what I want using other commands. My point was merely that everything you extract or calculate most likely has the potential for reuse.
    Why not build commands that facilitates the need for reuse. That goes for -list- too. Again: If it is worth showing, it is worth saving

    Leave a comment:


  • Franz Gerbig
    replied
    I'd wish to
    1. be notified, not only on the type of error, but of the - ideally linked - line of code it occurs in, as well.
    2. be able to use wildcards (at least *) in the variable pane of the dta and data-browser window
    3. have some way to save the bookmarks in my .do.

    Thanks for keepin it in mind

    Leave a comment:


  • John Mullahy
    replied
    [Subtopic: –margins– and –suest–] Given the way -margins- and -suest- are programmed this is perhaps an unreasonable request, but it would be nice to be able to combine a series of posted -margins- results using -suest-. E.g.
    Code:
    (some command)
    margins, dydx(*) post
    est store e1
    (some other command)
    margins, dydx(*) post
    est store e2
    suest e1 e2
    Now what one encounters is
    Code:
    . suest e1 e2
    e1 was estimated with a nonstandard vce (delta)
    r(322);
    I don't see why the delta-method computations used by -margins- preclude in principle the combination of multiple stored estimates, but it's quite possible I'm missing something obvious.

    Anyway, thanks for at least considering for v17.

    Leave a comment:


  • Clyde Schechter
    replied
    Re #101. I don't understand. If you have selected a subset of the data with -if- and -in- conditions, you can apply those conditions to nearly any subsequent command (and the ones you can't are just ones where it wouldn't make any sense). And if you want to retain that subset to work on separately, as of version 16 we can -frame put- them. Am I misunderstanding your meaning here?

    Leave a comment:

Working...
X