"== 1 invalid name" in rocreg (possibly also in outreg2)

[Thomas Mitterling]

Hey,

using rocreg (theoretically it could also be outreg2, but I'm pretty sure it's not) I more or less randomly get the error:

==1 invalid name
r(198);

I already tried to use Google and I found one thread from here (https://www.statalist.org/forums/for...9-invalid-name), but unfortunately the answer/solution has never been posted there. I am currently not able to replicate the error in a MWE. I'd be very thankful for any hints regarding this error (maybe they give me an idea where this could come from).

Thanks in advance!

edit:
Basically --rocreg-- is done for three different groups (always in a loop). First I got the error always at the same part of the code. I tried to leave the loop out where the error appeared but then it just appeared a bit later.

edit2:
I'm running the same code for lots of different settings in different instances of Stata. The interesting (and annoying) thing is that the error appears in literally all of them. Hence I'd assume that it has to do with Stata and not really my code, e.g. too many variables or something like that.

[William Lisowski]

This error has the appearance of an unset macro, like the following example

. list foo if `bar'==1
==1 invalid name
r(198);

where the local macro bar is undefined. If it comes from rocreg, it would be an error in the code: even if it is somehow precipitated by your data, the problem should be detected and an actionable error message given. If the problem is indeed in rocreg, you should probably report this to Stata Technical Services. But perhaps the problem is in your code driving the rocreg commands; you haven't shared your code so Statalist members cannot assess that. I will say that, empirically, on Statalist user errors far outnumber Stata errors.

With that said, while you've apparently done a lot of testing, you don't share the results of some of the basics. At this point you should be able to say definitively that the problem is in rocreg or in outreg2: just add display commands to your code before and after each of the two commands. While you tell us you cannot provide an MWE, you have not said whether or not the same combination of data and command will consistently fail, or not. Again, instrumenting your code by displaying key information before each rocreg command should help you determine this. I would expect that Stata Technical Services would want similar information.

Actually, on reflection, I'm not sure I understand what you mean by "running the same code for lots of different settings in different instances of Stata".

Bottom line: what you've told us could conceivably be a problem in Stata, but could also be a problem in your code misattributed to rocreg or outreg2.

[Thomas Mitterling]

Thanks, I found the mistake in the meantime. I misspelt the name of a macro (so you're right). The error Stata gave me also makes sense now.

To be honest, I expected to find something with Google in case of such a simple mistake (I hope that at least the next person with the same mistake finds this thread).

I will say that, empirically, on Statalist user errors far outnumber Stata errors.

Oh, I'm sure this is correct.

Since I usually copy&paste the name of macros I didn't expect the mistake to be there. After all the loops with rocreg and outreg2I have an if which uses a macro and this macro was misspelt. The code looks as follows:

if `level_model' == 1 {

replace model1_results = .

replace model2_results = .

}

The macro in red was one that didn't exist.

Thanks for your help!

[Nick Cox]

Good that you found the problem.

It's hard to know how this problem could be discovered from searching.

One formulation of the problem is that you may get strange results if you refer to entities that don't exist.

The Stataish twist that may bite, to mix metaphors, is that it is not in itself illegal to refer to macros that may be empty and Stata programmers do that all the time on purpose.

The bug source here is that there may be a side-effect that your syntax as a whole no longer makes sense. Stata will typically carry on and then sooner or later throw a syntax error at something that now is a puzzle it can't solve.

[Clyde Schechter]

I have, over the years, put on the "Wish List for Stata #" threads my preference for modifying this behavior of Stata's. Certainly there is already much code out there where non-existent macros are deliberately referred to, and we can't break that. But it would be a nice feature if one could -set- some parameter (which only takes effect in the current program and not down in programs called within it) which disallowed reference to non-existent macros, causing a break and an error message "non-existent macro reference." I would use that feature liberally were it available. Such a feature would have shown you the actual error from the start.

[Nick Cox]

Two positive hints:

1, If you read your own program or do file into Stata as string data, you can do part of this easily, namely to list all local definitions (that needs some modification if people ever write loca or loc and false positives are always positive).

2. When macros may be missing I pepper the code with

macro li

to get a brute force listing of what Stata knows about.