Local error: type mismatch r(109)

[Yingyi Lin]

Hi Statalist,

I have a seemly simple question below.

local zero=0
gen new_var =1 if old_var=="`zero'"

Pretty simple codes..but did not work with errors saying "type mismatch r(109);"


I also tred

local zero=0
gen new_var =1 if old_var==`zero'

still not working with error saying "invalid syntax r(198);"

Anyone could help me with this? (I already searched solutions online, but still cannot figure it out)

Thanks for any reply!
Yingyi

[William Lisowski]

Since you haven't told us anything about old_var, this is pretty much guesswork.

I think the first example failed because old_var is a numeric (byte, int, long, float, or double) variable and you are comparing it to a string constant.

I think the second example failed because you have written your code in the do-file editor window, and then rather than running everything at once, you are running it by selecting the first line and running it, then selecting the next line and running it. Consider the following example. In the do-file editor window, I have a two-line program that I run in its entirety.

. do "/var/folders/xr/lm5ccr996k7dspxs35yqzyt80000gp/T//SD30770.000000"

. local message Hello, world.

. display "`message'"
Hello, world.

.
end of do-file

Now I run the same two lines by selecting the first line and running it, then selecting the second line and running it.

. do "/var/folders/xr/lm5ccr996k7dspxs35yqzyt80000gp/T//SD30770.000000"

. local message Hello, world.

.
end of do-file

. do "/var/folders/xr/lm5ccr996k7dspxs35yqzyt80000gp/T//SD30770.000000"

. display "`message'"


.
end of do-file

The important thing to keep in mind is that local macros vanish when the do-file within which they were created ends. If you look carefully at the results above, you'll see that when I selected a single line to run, it was copied into a temporary do-file and run, so even though both lines are in the same window in the do-file editor, they are run as separate do-files, and local macro defined in the first line vanishes at the end of that do-file, and is undefined when the second line is run.

In your second example, when you ran the second line, the local macro zero had vanished, and your command was interpreted by Stata as

gen new_var =1 if old_var==

which is a syntax error. The first example ran because your command was interpreted by Stata as

gen new_var =1 if old_var==""

which is not a syntax error, but which compares a numeric variable to a string.

[Yingyi Lin]

Since you haven't told us anything about old_var, this is pretty much guesswork.

I think the first example failed because old_var is a numeric (byte, int, long, float, or double) variable and you are comparing it to a string constant.

I think the second example failed because you have written your code in the do-file editor window, and then rather than running everything at once, you are running it by selecting the first line and running it, then selecting the next line and running it. Consider the following example. In the do-file editor window, I have a two-line program that I run in its entirety.

. do "/var/folders/xr/lm5ccr996k7dspxs35yqzyt80000gp/T//SD30770.000000"

. local message Hello, world.

. display "`message'"
Hello, world.

.
end of do-file

Now I run the same two lines by selecting the first line and running it, then selecting the second line and running it.

. do "/var/folders/xr/lm5ccr996k7dspxs35yqzyt80000gp/T//SD30770.000000"

. local message Hello, world.

.
end of do-file

. do "/var/folders/xr/lm5ccr996k7dspxs35yqzyt80000gp/T//SD30770.000000"

. display "`message'"


.
end of do-file

The important thing to keep in mind is that local macros vanish when the do-file within which they were created ends. If you look carefully at the results above, you'll see that when I selected a single line to run, it was copied into a temporary do-file and run, so even though both lines are in the same window in the do-file editor, they are run as separate do-files, and local macro defined in the first line vanishes at the end of that do-file, and is undefined when the second line is run.

In your second example, when you ran the second line, the local macro zero had vanished, and your command was interpreted by Stata as

gen new_var =1 if old_var==

which is a syntax error. The first example ran because your command was interpreted by Stata as

gen new_var =1 if old_var==""

which is not a syntax error, but which compares a numeric variable to a string.

Hi William,

Thanks so much for your quick response. My second code works now!!! (just like you said, RUN THEM TOGETHER), I have never noticed that and kept running them separately. My old_var is a numeric variable. On top of these codes, I wonder if there is a way to resolve this "numerically-defined" macro into a string? Basically, I want to do this:

gen cut_point_0=1 if cut_point=0
gen cut_point_1=1 if cut_point=1
gen cut_point_2=1 if cut_point=2
(and so on)

 local cut_point=0
gen cut_point_"`cut_point'"=1 if cut_point==`cut_point'

But this code failed to resolve the variable I want as "cut_point_0", I wonder if there is a way to do this? Thanks!

Kindly,
Yingyi

[Clyde Schechter]

You don't say how many "and so on" is, but, just to illustrate, let's say it's 10 different values.

forvalues i = 1/10 {
     gen cut_point_`i' = `i'.cut_point
}

Note: This will not do exactly what you asked, but it will do what I believe you should have asked for. This will create a series of variables cut_point_* that take on the value 1 when cut_point = the suffixed value of the variable name, and zero elsewhere. Your code would have created 1/missing value variables instead of 1/0. Coding variables as 1/missing value is usually a bad idea in Stata, as in logical expressions, 1 and missing value are treated as equivalent. Also if you include variables like these in estimation commands, the missing values cause the observations to be dropped, and since every single observation would have some of these variables with missing values, you'd end up with no estimation sajmple at all! So you should avoid 1/missing value variables in nearly all circumstances.

Added: Also, think about whether you even need these variables at all. Indicator variables for the values of a categorical variable are seldom necessary in modern Stata. The factor variable notation i.cut_point will serve you equally well in most contexts, without taking up space in your memory. And in regression analyses, using i.cut_point will enable you to use the marvelous -margins- command afterward for adjusted margins. Do read -help fvvarlist-.

[Yingyi Lin]

You don't say how many "and so on" is, but, just to illustrate, let's say it's 10 different values.

forvalues i = 1/10 {
gen cut_point_`i' = `i'.cut_point
}

Note: This will not do exactly what you asked, but it will do what I believe you should have asked for. This will create a series of variables cut_point_* that take on the value 1 when cut_point = the suffixed value of the variable name, and zero elsewhere. Your code would have created 1/missing value variables instead of 1/0. Coding variables as 1/missing value is usually a bad idea in Stata, as in logical expressions, 1 and missing value are treated as equivalent. Also if you include variables like these in estimation commands, the missing values cause the observations to be dropped, and since every single observation would have some of these variables with missing values, you'd end up with no estimation sajmple at all! So you should avoid 1/missing value variables in nearly all circumstances.

Added: Also, think about whether you even need these variables at all. Indicator variables for the values of a categorical variable are seldom necessary in modern Stata. The factor variable notation i.cut_point will serve you equally well in most contexts, without taking up space in your memory. And in regression analyses, using i.cut_point will enable you to use the marvelous -margins- command afterward for adjusted margins. Do read -help fvvarlist-.

Hi Clyde, Thanks for your detailed response. The cut_points are not necessary sequential and limit to 10 or 100 (The upper limit is unknown). Thus, I am not actually looking for a "looping" strategy here, instead I am wondering if there is a way to "concatenate" string and numeric values to rename a variable using macro every time when I change the numeric values of the cut-point I chose. I guess there should be a way, but I ended up finding no references online as I have noticed.

[Clyde Schechter]

I take your response to mean that the variable cut_point has many possible values, and just how many is not necessarily known in advance. That's still a loop, just a slightly different one:

levelsof cut_point, local(cps)
foreach c of local cps {
    gen cut_point_`c' = `c'.cut_point
}

[Yingyi Lin]

You don't say how many "and so on" is, but, just to illustrate, let's say it's 10 different values.

forvalues i = 1/10 {
gen cut_point_`i' = `i'.cut_point
}

Note: This will not do exactly what you asked, but it will do what I believe you should have asked for. This will create a series of variables cut_point_* that take on the value 1 when cut_point = the suffixed value of the variable name, and zero elsewhere. Your code would have created 1/missing value variables instead of 1/0. Coding variables as 1/missing value is usually a bad idea in Stata, as in logical expressions, 1 and missing value are treated as equivalent. Also if you include variables like these in estimation commands, the missing values cause the observations to be dropped, and since every single observation would have some of these variables with missing values, you'd end up with no estimation sajmple at all! So you should avoid 1/missing value variables in nearly all circumstances.

Added: Also, think about whether you even need these variables at all. Indicator variables for the values of a categorical variable are seldom necessary in modern Stata. The factor variable notation i.cut_point will serve you equally well in most contexts, without taking up space in your memory. And in regression analyses, using i.cut_point will enable you to use the marvelous -margins- command afterward for adjusted margins. Do read -help fvvarlist-.

Hi Clyde, more specifically, codes I have now are

local low_cutpoint=0
gen low_0=1 if var==`low_cutpoint'
egen low_0_sum=sum(low_0)


local low_cutpoint=35
gen low_35=1 if var==`low_cutpoint'
egen low_35_sum=sum(low_35)

Basically, every time when I changed the cutpoint value, I also want the two new variables ( low_`cutpoint' & low_`cutpoint'_sum ) be renamed with the that change of new cutpoint values.

[Yingyi Lin]

I take your response to mean that the variable cut_point has many possible values, and just how many is not necessarily known in advance. That's still a loop, just a slightly different one:

levelsof cut_point, local(cps)
foreach c of local cps {
gen cut_point_`c' = `c'.cut_point
}

Hi Clyde, what does "cps" mean here? Sorry I am confused....

[Yingyi Lin]

Hi Clyde, please disregard my questions all above, I think I figured it out

local zero_cut=0
gen zero_`zero_cut' = 1 if var ==`zero_cut'
replace zero_`zero_cut' = 0 if zero_`zero_cut' ==.
egen zero_day_`zero_cut'= sum(zero_`zero_cut')

It seems like what I have to do is to RUN ALL THESE CODES TOGETHER.... All I want is no need to change variable name every time I change the value of the local variable.
Still Thanks a lot Clyde!

[William Lisowski]

The important thing to keep in mind is that local macros vanish when the do-file within which they were created ends. If you selected your first line to run, it was copied into a temporary do-file and run, so even though all four lines are in the same window in the do-file editor, they are run as separate do-files, and local macro defined in the first line vanishes at the end of that do-file, and is undefined when the second line is run.

[Yingyi Lin]

The important thing to keep in mind is that local macros vanish when the do-file within which they were created ends. If you selected your first line to run, it was copied into a temporary do-file and run, so even though all four lines are in the same window in the do-file editor, they are run as separate do-files, and local macro defined in the first line vanishes at the end of that do-file, and is undefined when the second line is run.

Thanks for this important note William! It really helps a lot to people like me who are new to Stata. Thanks again~