Announcement

Collapse
No announcement yet.
This is a sticky topic.
X
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #91
    - Power command should include covariate adjustment
    - also when I run a do file and I save large excel files with export excel, the do files blocks and I can't code while my code is running. I don't know why stata does that but this would be nice if I could still code while running a command.

    Comment


    • #92
      The command xtpoisson, especially with the fe option, should allow vce(cluster gid) for generalidentifiers gid. Currently, vce(robust) is the same as vce(cluster id) after xtset id. But this forces one to cluster at the same level as the unit fixed effects. One often wants to cluster at a higher level than the cross-sectional identifier. For example, I have firm level data but variation in, say, a regulation is at the industry level. Then I should be able to type

      Code:
      xtset firmid year
      xtpoisson y x1 ... xK i.year, fe vce(cluster industryid)
      If I use vce(cluster firmid) then that should be the same as what is currently allowed, vce(robust). This is a fairly easy fix. There is a community contributed command, xtpqml, written by Tim Simcoe, that does allow clustering at different levels. I think it should be part of official Stata.

      Comment


      • #93
        As a follow up to #92, I just noticed that in Stata 19, if you use the re option, vce(cluster gid) is allowed! But not for fe. That asymmetry is not justified from a statistical perspective. I'm hard pressed to think of and case where you wouldn't want the option to cluster. We can apply any estimation method on data indexed by units id and then we might have reason to cluster at a higher level, gid.

        Comment


        • #94
          Possibly consider the addition of Quad storage type in Stata. Seems like Mata has it though.

          Comment


          • #95
            Originally posted by Fahad Mirza View Post
            Possibly consider the addition of Quad storage type in Stata. Seems like Mata has it though.
            Many underlying routines in Strata and Mata operate with quad precision before returning results to store as double (or lower) storage types. What is use case to have quad precision storage?

            Comment


            • #96
              I personally wish to see more support for omics analysis, more integration for machine learning and AI, more support for genomics and proteomics data analysis (also data visualization of the outputs), twin- and family-based studies (more extensions to structural equation modeling), and maybe split screen function for do-files?

              Comment


              • #97
                I've been using Stata 17 so it's possible this has all been dramatically improved, and if so I apologize for derailing the thread.

                But:

                At this point what I want is debugging tools / guidance, better syntax highlighting and checking, etc. When something breaks, I want to know what line of code it broke on, and if possible, a more informative error message. This is one area where the RStudio IDE totally cleans Stata's clock.

                Comment


                • #98
                  I would be very happy to have "variables window" directly in do-file editor accessible. When I write do-file with large dataset, i have to return quite often to search for variables names etc.

                  Comment


                  • #99
                    Originally posted by Matej Seifert View Post
                    I would be very happy to have "variables window" directly in do-file editor accessible. When I write do-file with large dataset, i have to return quite often to search for variables names etc.
                    This wouldn't work in the Do-file Editor since it's largely context unaware between the code being written and the dataset loaded in active memory. However, you can use the main Stata window or the Browse window to see the variable name pane which lists variable names and labels (the browse window additionally shows formats and data types). If you have an idea of the variable name, you can use tab-autocompletion in the Command pane in the main Stata window. Lastly, if you have already typed a variable name in your current do-file, autocompletion will allow you to access it again.

                    Comment


                    • Originally posted by Matej Seifert View Post
                      I would be very happy to have "variables window" directly in do-file editor accessible. When I write do-file with large dataset, i have to return quite often to search for variables names etc.
                      Variable name completion is available in the Do-file Editor but the variable names are mixed in with all the other auto completion words in the list that's presented.
                      -Chinh Nguyen

                      Comment


                      • it would be great, for me at least, if one could limit the use of find, and find-and-replace, within the do-file editor to highlighted blocks of code

                        Comment


                        • Re #101:

                          The do-file editor's find and replace does allow you to restrict to a selected block of code. At the very bottom of the replace window that pops up, check the box for "Replace all in selection."

                          This functionality is not, however, available, for find.

                          Comment


                          • re: #102 - thanks Clyde Schechter ; I did miss this somehow

                            Comment


                            • Originally posted by Pete RT View Post
                              Update the Linux/Unix user interface and and port it to GTK4. This will heavily improve window management and Wayland support on Linux/Unix!

                              The Linux/Unix version of Stata 19 (the main UI and the do file editor) still relies on the very outdated graphical toolkit GTK2. Therefore, Stata does not support Wayland which is the standard windowing system for quite some while.
                              The current Stata UI looks outdated on current Linux/Unix systems. GTK4 is the current version of the toolkit, which supports Wayland and X11 out of the box. The current Stata UI causes some real-life problems: Sometimes, the Stata window is not resizable anymore. This is particularly the case, when having switched between external display <> internal display. Sometimes, the clipboard is not triggered which makes copy&paste painful. The upgrade of the UI to GTK4 will solve these problems and gives many other benefits of an up-to-date UI toolkit (e.g. performance, stability, ...)
                              Update as of Jan 2026: The influential Linux distribution Debian plans to remove GTK2 in the upcoming version Debian 14 (to be released in early 2027). As many distributions depend on Debian, this means that Stata, that still depends on the outdated GTK2, will not run anymore on Linux. Please update the Stata 20 user interface to the current GTK4.

                              Comment


                              • With the right queries, I can get pretty good R or Python coding suggestions from LLM sources. Not being an expert on this topic, will this be part of a future Stata? My understanding is that LLMs are better with popular languages.

                                Comment

                                Working...
                                X