Announcement

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

  • #16

    It will be very helpful if the next version of Stata provides easy access to operating system metrics (through c-class values perhaps). For example:

    Code:
     - the number of monitors
     - the resolution of each monitor
     - an indicator about whether a Stata window is maximised
     - the Stata results window dimensions
     - the number of monitors that the Stata results window spans across

    It would also be great if the programmer can dynamically adjust the dimensions of the Stata results window and can set where a dialog box appears on screen.

    Comment


    • #17
      Originally posted by Nigel Moore View Post
      AFAIK, the two Dunnet's supported by Stata require balanced data sets, certainly Theresa Powell's does)
      Confirmed, -pwcompare, mcompare(dunnett)- does require balanced datasets.

      In the biological/medical sciences we may well start off with balanced designs, but we often end up with unbalanced datasets. Other software packages can deal with this. In 2017 why cannot Stata? It's pretty lame.
      Stata 14.2MP
      OS X

      Comment


      • #18
        In addition, to the various enhancements that others have suggested for the do file editor, i would really like to see permanent bookmarks. Every time i close Stata or if there is a crash, all my bookmarks disappear, which is very annoying as it is very time-consuming to set them all up again. And that's assuming i can remember them all!

        Comment


        • #19
          It would be nice (but not essential) if the keep command had an "order" option, which orders the variables you keep in the order you specify them in the command. This is of course trivial to implement as a user-written command, but it's something I find myself doing quite regularly. Doing it manually every time is a bit inconvenient because the actual variables to keep might change regularly and then it's a hassle to change it in both. Using a local varlist seems overkill.
          Last edited by Jesse Wursten; 15 Sep 2017, 07:53.

          Comment


          • #20
            Originally posted by Jesse Wursten View Post
            It would be nice (but not essential) if the keep command had an "order" option, which orders the variables you keep in the order you specify them in the command. This is of course trivial to implement as a user-written command, but it's something I find myself doing quite regularly. Doing it manually every time is a bit inconvenient because the actual variables to keep might change regularly and then it's a hassle to change it in both. Using a local varlist seems overkill.
            I recently found myself trying to use
            Code:
            keep varlist if exp
            to avoid two -drop- commands (one to drop the unwanted variables, the other to truncate the desired variables to a subset.) Being able to mix varlist and if options with -keep- and -drop- would be nice.
            Stata 14.2MP
            OS X

            Comment


            • #21
              I have several requests:

              1) All input and output commands should allow subsetting by variable or observation. I find it frustrating that to
              save a national file into 51 separate files (one for each state) I have to reread the national file 50 times.

              2) Merge is very slow compared in use - order(s) of magnitude slower. Also, it would be nice if the user could (optionally)
              specify the amount of memory required for the result, so that cases where the Stata estimate is larger than available memory,
              but smaller than the true requirement, could still be run. We run into this at NBER because typically only a tiny fraction
              of a very large dataset is kept.

              3) An attempt to use the -if- command with a variable should return an error (or at least a warning) rather than using the
              first observation.

              4) Provide a way to suppress the "NNN values changed" message in do files, without suppressing actual error messages..

              5) Provide a way to add the variable name to the "NNN values changed" message.

              6) Allow http uploads as well as downloads. We operate a remote SAAS that calculates income tax liability. Currently
              we provide an ado file (-taxsim9.ado-) that invoke ftp to upload the data, but that is a hack.

              Comment


              • #22
                Re #20: I don't think that would be a good idea. It would make the semantics of -if- qualifiers different for just the -keep- and -drop- commands. The -if- qualifier is very specific: it identifies a subset of the observations to which the command will be applied. That's not relevant to -keep-ing and -drop-ing variables. Some more flexible syntax for specifying varlists beyond what is afforded by wildcards might be useful, for this and other purposes, but overloading -if- to do it would, in my view, be an invitation to trouble.

                Re #21:

                1) See https://www.statalist.org/forums/for...-inside-a-loop for a way around this limitation. You still have to do 50 read operations, but they do not read the entire data set each time.

                2) If the subset of the using data that will be needed for any given observation can be specified by an interval to which the value of a variable belongs, then Robert Picard's -rangejoin- command will handle this, and it is much faster than -merge-. See also Sergio Correa's -ftools- package, which deals with the speed issue. (I don't know if it also deals with the memory issue.)

                3) Yes, I agree. This behavior is quite unexpected, and the syntactic acceptance of a vector where only a scalar is admissible leads unwary users down the garden path. More important than the number of people who post here because of their "inexplicable" results from doing this, is the possibly larger number of people who are producing garbage results and are completely unaware of it! On the other hand, Stata has always been fairly generous in allowing people to take shortcuts in syntax that reduce typing. I suspect there is a fair amount of legacy code out there that relies on this convention and would break if this change were made. Perhaps implementing this prohibition, but allowing it under version control would be a reasonable compromise.

                4) Why isn't -quietly- the solution to this?

                5) Yes, that might be helpful.

                6) No comment. Not relevant to my work, but I can see where this would be useful to others. On the other hand, I wonder if there are unintended consequences.
                Last edited by Clyde Schechter; 24 Sep 2017, 10:38.

                Comment


                • #23
                  Making nestreg support factor variable operators would be a nice improvement, IMO. Is there some technical reason why this is not currently supported?

                  Cheers,
                  Bruce
                  --
                  Bruce Weaver
                  Email: [email protected]
                  Version: Stata/MP 18.5 (Windows)

                  Comment


                  • #24
                    Originally posted by Bruce Weaver View Post
                    Making nestreg support factor variable operators would be a nice improvement, IMO. Is there some technical reason why this is not currently supported?

                    Cheers,
                    Bruce
                    I agree. But I'll note that, much a I hate hate hate the old xi: prefix, you could use it with nestreg if you want to avoid creating dummies and interaction yourself.
                    -------------------------------------------
                    Richard Williams, Notre Dame Dept of Sociology
                    Stata Version: 17.0 MP (2 processor)

                    EMAIL: [email protected]
                    WWW: https://www3.nd.edu/~rwilliam

                    Comment


                    • #25
                      Originally posted by Clyde Schechter View Post
                      Re #20: I don't think that would be a good idea. It would make the semantics of -if- qualifiers different for just the -keep- and -drop- commands. The -if- qualifier is very specific: it identifies a subset of the observations to which the command will be applied. That's not relevant to -keep-ing and -drop-ing variables.
                      I'm not sure that I follow your logic, Clyde. Using the -if- qualifier with -keep- and -drop- limits those commands to the subset just like any other command.
                      Stata 14.2MP
                      OS X

                      Comment


                      • #26
                        Clyde's point, I imagine, is that using variables and also an if qualifier would not be consistent with other syntax. Consider

                        Code:
                        summarize x y if foo == 42 


                        There is no problem here because selecting on variables and selecting on observations are just different ways of selecting data and compatible with each other.

                        But


                        Code:
                        keep x y


                        Code:
                         keep if foo == 42
                        select data in different dimensions: you can keep (or drop) variables OR you can do that to observations. As far as Stata is concerned

                        Code:
                         keep x y if foo == 42
                        could only mean selecting in both directions at once, which at its simplest is cutting a rectangular hole in the dataset and throwing the data away, which Stata doesn't allow. .

                        I (we) understand that you want

                        Code:
                        keep x y if foo == 42
                        to be acceptable short-hand for

                        Code:
                        keep x y
                        keep if foo == 42
                        but I too would support StataCorp never, ever allowing that. Consider that

                        Code:
                        summarize x y 
                        summarize if foo == 42
                        are not at all equivalent to

                        Code:
                        summarize x y if foo == 42
                        But you can program this for yourself! Something like

                        Code:
                        * not recommended by its author 
                        program nigelkeep 
                           syntax [varlist] [if] 
                           if `"`varlist'`if'"' == "" error 198 
                           if "`varlist'" != "" keep `varlist' 
                           if `"`if'"' != "" keep `if' 
                        end

                        Comment


                        • #27
                          Stata frequently tells me I need a bigger matsize for the problem I am running. So, I give commands like

                          set matsize 7500

                          This is a pain. When I run equivalent models in Mplus or lavaan, they don't whine at me about such things. I wish Stata could just set the matsize dynamically. Or at least give better messages about what the matsize needed to be set to. I don't want to experiment to have to figure out what the optimal matsize is for every problem.
                          -------------------------------------------
                          Richard Williams, Notre Dame Dept of Sociology
                          Stata Version: 17.0 MP (2 processor)

                          EMAIL: [email protected]
                          WWW: https://www3.nd.edu/~rwilliam

                          Comment


                          • #28
                            Originally posted by Richard Williams View Post
                            Stata frequently tells me I need a bigger matsize for the problem I am running. So, I give commands like

                            set matsize 7500

                            This is a pain. When I run equivalent models in Mplus or lavaan, they don't whine at me about such things. I wish Stata could just set the matsize dynamically. Or at least give better messages about what the matsize needed to be set to. I don't want to experiment to have to figure out what the optimal matsize is for every problem.
                            Is there even a reason you can set a lower matsize? I did set matsize 11000, permanently at some point and I don't think that's ever hurt me in any way?

                            Comment


                            • #29
                              Originally posted by Jesse Wursten View Post

                              Is there even a reason you can set a lower matsize? I did set matsize 11000, permanently at some point and I don't think that's ever hurt me in any way?
                              See this thread for a discussion:

                              https://www.statalist.org/forums/for...ng-set-matsize

                              I would like to do what you did if I can be convinced it won't hurt me, but there are differing statements on this.
                              -------------------------------------------
                              Richard Williams, Notre Dame Dept of Sociology
                              Stata Version: 17.0 MP (2 processor)

                              EMAIL: [email protected]
                              WWW: https://www3.nd.edu/~rwilliam

                              Comment


                              • #30
                                Originally posted by Richard Williams View Post

                                See this thread for a discussion:

                                https://www.statalist.org/forums/for...ng-set-matsize

                                I would like to do what you did if I can be convinced it won't hurt me, but there are differing statements on this.
                                Ah, good to know.

                                An unrelated request for Stata 16. This may be a Microsoft Windows thing, but imagine you create three instances of Stata. Then you will have Stata, 2 - Stata and 3 - Stata as window titles. This is great. What I would thoroughly appreciate is that the same applies to dofile editors and data browsers. That is, if I type browse in 2 - Stata, then I'd like the browse window to be 2 - Data Browser and doedit leads to 2 - Do-file Editor.

                                Now, I often have multiple instances of Stata open which I can tell apart, but lose track of which browse and dofile editor window corresponds to which Stata. Especially when you try to do some manual parallelisation or are just working on multiple similar datasets at the same time, this gets confusing quite quickly.

                                EDIT:
                                Stretch goal 1: move the name of the dataset loaded to the front of the window titles
                                Stretch goal 2: let us name the windows ourselves (potentially as option in the use command)
                                Last edited by Jesse Wursten; 28 Sep 2017, 05:03.

                                Comment

                                Working...
                                X