Stata error 101 (factor-variable operators not allowed)

[Dirk Enzmann]

I can't see why the following syntax generates a Stata error message in line 65 ("factor-variable operators not allowed") if I run it as a .do-file. But if I only select lines 37 ("// Ethnicity:") until 68 ("log off") it runs without error:

/* Stata error 101 in row 65:  */ 
clear all 
version 9 
 
global outp "/datadisk/Projekte/CCCC_Review/" 
cap log close 
log using "${outp}rean_tab_17-9.smcl", replace 
 
// Reanalysis Table 17.19 (p. 316) 
 
* ------------------------------------------------------------------------------ 
// Gender: 
clear 
input female exposure n 
  0 0 296 
  0 1  58 
  1 0 304 
  1 1  52 
end 
 
lab def female 0 "male" 1 "female" 
lab val female female 
lab var female "Gender" 
 
lab def exposure 0 "low" 1 "high" 
lab val exposure exposure 
lab var exposure "Exposure" 
 
expand n 
 
tab2 female exposure, col chi2 
tab2 female exposure, row chi2 
 
log off 
* ------------------------------------------------------------------------------ 
// Ethnicity: 
clear 
input ethnicity exposure n 
  0 0 495 
  0 1  94 
  1 0  68 
  1 1   4 
  2 0  33 
  2 1  10 
  3 0   4 
  3 1   2 
end 
 
lab def ethnicity 0 "White" 1 "Asian" 2 "mixed" 3 "Black" 
lab val ethnicity ethnicity 
lab var ethnicity "ethnicity" 
 
lab def exposure 0 "low" 1 "high" 
lab val exposure exposure 
lab var exposure "Exposure" 
 
expand n 
 
log on 
 
tab2 ethnicity exposure, col chi2 
tab2 ethnicity exposure, row chi2 
 
qui logistic exposure i.ethnicity, or 
margins ethnicity, pwcompare(pv) mcompare(sidak) 
 
log off

I'm probably overlooking something, but I can't see what it is.

[Joseph Coveney]

I can't see why the following syntax generates a Stata error message in line 65 . . .

Because you put version 9 in line 2.

Did you mean version 19?

[Dirk Enzmann]

Thanks, that solves it!

I actually meant 9 (I wanted to have syntax that will run also with earlier Stata versions), but I was not aware that factor-variables were introduced only with Stata 11 (it seems). Hence, I will write version 11, instead.

[daniel klein]

I actually meant 9 (I wanted to have syntax that will run also with earlier Stata versions), [...]. Hence, I will write version 11, instead.

That won't work either. The pwcommpare() option was added to margins in release 12. As usual, declaring an old version won't make new code run on older copies of the software.

[Dirk Enzmann]

daniel klein : Thank you for your comment concerning the (working of) margins options in different Stata versions!

Now I have two additional problems (I think it is OK not to open a new thread or topic for problem 2):

(1) After I did change version 9 to version 11 the syntax run without problems. But a text comparison of outputs files (a) (using version 11) and (b) (using version 12) does not show any difference. How is this possible if pwcompare() was added in release 12?

(2) Up to now I thought that when writing programs it would be is useful to specify version with the smallest possible release number if you want that the program will run with as many earlier Stata releases as possible. However, having a look at the long list presented in "Summary of version changes" in help version, it seems that I shouldn't try to do this because it is extremely difficult to keep track of the changes. Hence: Does this mean that when writing programs we want to publish (e.g. at SSC) we should always set version to the most recent version and that we should not attempt to use earlier release numbers?

[daniel klein]

Stata's concept of version control is often misunderstood. The simplest way I can put it is this: version is not meant to make new code run in old releases of the software; version ensures that current code will continue to run in future versions of the software. Thus, the short answer to your second question is: Always declare the version you're currently using. There is no way to ensure your code runs in older releases of Stata, except by running it on a physical copy of older releases. Your first question demonstrates this point. When you run the code on a copy of Stata 11, you'll get a syntax error:

. about

Stata/IC 11.2 for Windows (32-bit)
Born 16 Feb 2012
Copyright 1985-2009 StataCorp LP

Total physical memory:     2097151 KB
Available physical memory: 2097151 KB

Single-user Stata perpetual license:
       Serial number:  *********81
         Licensed to:  Daniel Klein
                       Otto-Friedrich-Universität

. sysuse nlsw88
(NLSW, 1988 extract)

. logistic union i.collgrad

Logistic regression                               Number of obs   =       1878
                                                  LR chi2(1)      =      17.30
                                                  Prob > chi2     =     0.0000
Log likelihood = -1037.9748                       Pseudo R2       =     0.0083

------------------------------------------------------------------------------
       union | Odds Ratio   Std. Err.      z    P>|z|     [95% Conf. Interval]
-------------+----------------------------------------------------------------
  1.collgrad |    1.64747   .1951016     4.22   0.000     1.306213    2.077883
------------------------------------------------------------------------------

. margins collgrad , pwcompare
option pwcompare not allowed
r(198);

You won't get that on Stata 12 or later.

[daniel klein]

Although the following is speculative to some extent, here's how the described situation may arise. Suppose you're StataCorp and you have written a command foo as

program foo
    
    version 9
    
    syntax varlist
    
    ...
    
end

and release it in Stata 9.

For Stata 11, you decide to make foo better in some way. The old behavior is valid, though. To make sure that old code continues to produce the same results, you put the changes under version control. You may write

program foo
    
    version 9
    
    if (_caller() < 11) {
        
        version `=_caller()' : foo_9 `0'
        
        exit
        
    }
    
    version 11
    
    syntax varlist(fv)
    
    ...
    
end

Note that above, you keep the version 9 statement, so old code won't break. When version is set to less than 11 (this is what _caller() returns), you pass the input as typed (`0') to foo_9, a copy of the original foo, and exit. You make sure to pass the _caller() version along, but that's a different story.

Anyway, when version is 11 or higher, you [optionally] set version to 11, allow factor variables and implement your new code. Note that you do not bother implementing factor variable notation in foo_9. Why should you? All version is supposed to do is keep old code alive. It does. A dofile written as

version 9
foo varname

continues to work - and yields the same results. A dofile written as

version 9
foo i.varname

will not work. It would not have worked before Stata 11 was released either.

Moving on. For Stata 12, you decide to add a new option, bar:

program foo
    
    version 9
    
    if (_caller() < 11) {
        
        version `=_caller()' : foo_9 `0'
        
        exit
        
    }
    
    version 11
    
    syntax varlist(fv) [ , bar ]
    
    ...
    
end

Although the new option bar may change the behavior of foo, there's no need for version control here, because old code could not have specified that option. You don't bother implementing bar in foo_9. Anyway,

version 11
foo varname , bar

would have been illegal syntax in Stata 11, but it is perfectly legal in Stata 12. Again, you only worry about not breaking old code. You don't break old code by introducing new options.

I hope this example, while slightly complex, illustrates the point.

[Nick Cox]

Let me mention an FAQ https://www.stata.com/support/faqs/p...stata-version/

A small confession: That FAQ was written, like many others, as a way to present a systematic survey of something puzzling people on Statalist. The confession is just that I thought the FAQ would be much shorter than it ended up being and easier to write than it was.

A short answer to one of Dirk Enzmann 's questions is that whatever you do is likely to be defensible -- and possibly could go wrong for users and programmers alike. Some people develop a command for version x and declare that and in effect are saying conservatively "I believe this works for version x but I make no claims about earlier versions". Others (I am usually among them) make informed guesses about what version is needed for a program to work. That may seem cavalier, but I am mindful of people and workplaces that have problems raising the money for new licences. (That may now include many universities in prosperous countries!) That can cause problems which in turn can usually be fixed -- if only to revise code and documentation because you really need version y (y > x) for a command to work,

[Dirk Enzmann]

Nick Cox : My conclusion from this concerning my question (2) in #5: A programmer should have the earlier version that is specified at the start of the program installed and write (and test) the program in that version because it is hard to make an "informed" guess by going through the long list of changes in "Summary of version changes" as shown in help version. Do you agree?

[Nick Cox]

As said, people can and should make their own choices. But it is hard to know why someone would want to make a command public if they haven't studied Stata provision in the same territory and know about the commands they are using.

A long while back someone mentioned what they saw as major limitations of an official command and announced that they would write a much more general replacement. There followed a series of questions about this or that part of the code which revealed all too painfully that they didn't really understand Stata or Stata programming at all well. The questions faded away; the announced command never appeared; and I imagine that the poster realised sooner or later that their proposal was too ambitious for their skillset.

The point of the story is that this kind of occurrence is rare. Most people who get to write their own command usually have good self-awareness of what they can do, and in any case how does one grow except by trying something a little ambitious? Perhaps their code needs some small fix, which is what it is: they join the club of briefly embarrassed programmers.

[daniel klein]

Nick Cox and I answered different questions. I was focusing on the question of what version does and doesn't. Nick was focusing on the question of what a programmer might do, which may be closer to Dirk Enzmann's original question (2). There's nothing wrong with a programmer declaring an older version than they use; there's just no guarantee that their program will actually run in the declared version.

There are two reasons I typically don't make educated guesses:

1. In my program, I call other programs, and I typically want the most recent behavior of these programs

2. When others use my programs in earlier versions of Stata, I prefer them to see an error message like

this is version 18.0 of Stata; it cannot run version 19.0 programs
     You can purchase the latest version of Stata by visiting https://www.stata.com.
r(9);

which clearly describes the problem, over something like

option pwcompare not allowed
r(198);

which may or may not relate to what they have typed.