Announcement

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

  • rename old* new* : error message "variable old not found"

    When running a lengthy .do-file containing the command
    Code:
    rename snat* pick*
    to rename several variables with the prefix "snat" into variables with the prefix "pick", I receive error r(111) "variable snat not found". What is strange: When I select the command in the .do-file editor a second time and run it again, the rename command works as it should.

    Any ideas what is going on? I set variable abbreviations off by using
    Code:
    set varabbrev off, perm
    Also note that I explicitely dropped any temporary variables (not doing this may result in strange and unexpected behavior, as I recently learned, see temporary-names-for-a-scalar-dangerous-advice).

  • #2
    To help locating the problem I tried two things:

    (1) Put the command into a different .do-file and call that .do-file from the original .do-file instead of using the rename command directly: The problem persists.

    (2) Do not run the complete .do file containing the rename command but instead select and run the section before this command and subsequently select this (and the remaining commands of the .do-file) and run it: The problem disappears.

    However, this is not a very useful workaround.

    Comment


    • #3
      I can't replicate. Can you produce a replicable problem? I have this theory that 90% of all weird problems are solved by rebooting the machine, or at least exiting and restarting the program.
      -------------------------------------------
      Richard Williams, Notre Dame Dept of Sociology
      Stata Version: 17.0 MP (2 processor)

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

      Comment


      • #4
        No, the problem does not disappear by restarting Stata nor by rebooting the machine and restarting Stata. The problem is thus replicable, but I can't conceive of a way to replicate the problem with other data and a different set of .do-files.
        Last edited by Dirk Enzmann; 21 Aug 2014, 19:51.

        Comment


        • #5
          Very odd. Not sure what else to suggest, unless you are free to share your entire data set and do file.
          -------------------------------------------
          Richard Williams, Notre Dame Dept of Sociology
          Stata Version: 17.0 MP (2 processor)

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

          Comment


          • #6
            Thanks of pondering. I am sending a one-case data set (still reproducing the problem) plus all .do-files to Stata TechSupport. I guess it will not be easy to track down the problem (at least without a good theory).

            Comment


            • #7
              Stata Technical Support did locate the problem. The possibility to change the prefix of variables by using rename was introduced in Stata 12. However, I used the command in a .do-file with version control. If you are using
              Code:
              version 11
              gen snat01 = .
              gen snat02 = .
              rename snat* pick*
              Stata 12 or 13 will issue error r(111) "variable snat not found" -- Stata 13 will behave as Stata 11. This also explains why the rename command worked as intended when subsequently I did select the syntax and run only the selection as a .do-file (which did not contain version 11). Going back to Stata 11 under version control I should have used
              Code:
              version 11
              gen snat01 = .
              gen snat02 = .
              renpfix snat pick
              instead. Note that renpfix still works in Stata 13.

              Comment


              • #8
                Thanks for this explanation, which is perfectly understandable. However ...

                I must confess, some parts of the version control system remain a mystery to me. Why is this behavior not documented in help version?

                I do not fully understand which new features work (even) with version control (which has often been said not to be a "time-machine") and which do not. For example, if you set version to less than 11, factor variables cannot be used. You can, however, use a variable list with the label values command with version set to less than 10. Neither is documented.

                Is the rule that "major" new features cannot be used with version set prior to their introduction? If so, why can we use the 1:1, 1:m, ... qualifiers with merge even if version is set to less than 11?

                Just wondering.

                Daniel

                Comment


                • #9
                  Daniel:

                  It's a very good question. I understand that version control is intended to give you an old behaviour when you might have a good reason to prefer it. But StataCorp rule on what is a good reason. Wanting to replicate a bug that has been fixed would not be a good reason.

                  This behaviour with rename should, I guess, be documented.

                  Comment


                  • #10
                    According to the help file for version:

                    However, some changes in Stata will break old programs unless the version number is set
                    back to the appropriate version number. The list below outlines these important
                    changes. This list is probably of interest only to those trying to update an old
                    program to a new version's syntax -- most people will just set the version number
                    appropriately instead and not worry about any of this.
                    Accordingly, the typical use of version is to make your programs forward compatible, i.e., so that they will continue to work even if a future version of Stata breaks your code. As Nick points out, version control can also be used to give you old behavior, although I doubt that was the intention. The help file for version provides a summary of the major changes that might break old programs if you don't use version control.

                    Dick's problem, however, does not relate to either of these uses. He uses version control, but then used a syntax that did not exist as of that version. Stata 13 correctly ascertained that rename using wildcards did not exist in version 11 and threw an error. The fact that Stata occasionally allows you to get away with using new syntax with old version numbers (for it's own reasons) does not obligate it to inform us of such exceptions.

                    It seem to me that it is bad programming practice to use new syntax with an old version number, as there are no guarantees that it will actually work with an actual instance of the old version. Again, version control was intended for future compatibility and assumes the author indicates the version he/she is currently working with. Using it for backward compatibility is somewhat dangerous (as Dick illustrates) because it requires an encyclopedic knowledge of every change to every Stata version in order to make sure your syntax was actually valid under the old version. Stata helped out in this case by giving an error, but as Daniel notes that will not always be the case.

                    Comment


                    • #11
                      -help version- has a long section on "Summary of version changes". Changes in the behavior of -rename- are not discussed.

                      With regards to replicating a bug -- it looks like Stata will let you do it sometimes. If you set version to less than 9.1, it says

                      "logit, probit, and dprobit will accept aweights. Support for aweights was removed from these commands because the interpretation of aweighted data is nonsensical for these models."

                      I think version control often just results in the entire earlier program being run. I am guessing that is true for rename. In other cases, maybe some hybrid of old and new code is used.

                      Anyway I am going to add "version control" to my list of things that can produce seemingly bizarre and inexplicable behavior.
                      -------------------------------------------
                      Richard Williams, Notre Dame Dept of Sociology
                      Stata Version: 17.0 MP (2 processor)

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

                      Comment

                      Working...
                      X