Type mismatch error, variable renaming

[Konrad Zdeb]

Colleagues,

I'm trying to remove a set of characters from the middle of variable name. Following previous discussions, I'm trying the following code but I keep on getting the type mismatch error.

foreach var of varlist somevariablename22 - somevariablename89 {
    local newname = substr(`var',13,length(`var') - 4)
    rename `var' `newname'
    }

Fixed, the inverted commas were missing.

foreach var of varlist somevariablename22 - somevariablename89 {
    local newname = substr("`var'",13,length("`var'") - 4)
    rename `var' `newname'
    }

[Joe Canner]

renvars (from SSC) is a good tool for this since you can do it in one line and not have to remember as much syntax:

renvars somevariablename22-somevariablename89, map(substr("@",13,length("@")-4)

[Nick Cox]

renvars is from Stata Journal. There is no version on SSC.

[Konrad Zdeb]

Joe,

Thanks for your input I find renvars extremely useful. I came across an old discussion that suggested loop-based solution and progress in that direction. Your solution is better.

[DannyBulls]

Dear all,

I am preparing my panel dataset. After a merge, I used the cmd

.destring, replace

In order to define numeric and string variables.
All is ok. But when i tried to reshape data, using

.reshape long varlist, i(id) j(years)

I got this error:

"kft12 type mismatch with other kft variables"

I checked for type mismatch but I did not find it. In fact, as I can see from the window of properties, the kft12's type is "str30" and this is the same of other kft variables.

Do you had this problem before?

Thank you in advance for the help.

D.

[Nick Cox]

My experience is that Stata is always right on these issues. Please show us the exact reshape command you used (not an approximation) and the results of

 
describe kft*

[DannyBulls]

Dear Nick,
here is the output.

. reshape long cc sel si sic cs inda asf k kft s sft, i(wsid) j(year)
(note: j = 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29)
kft12 type mismatch with other kft variables
r(198);

. desc kft*

storage display value
variable name type format label variable label
-------------------------------------------------------------------------------
kft1 byte %10.0g kft1
kft2 byte %10.0g kft2
kft3 byte %10.0g kft3
kft4 byte %10.0g kft4
kft5 byte %10.0g kft5
kft6 byte %10.0g kft6
kft7 byte %10.0g kft7
kft8 byte %10.0g kft8
kft9 byte %10.0g kft9
kft10 byte %10.0g kft10
kft11 byte %10.0g kft11
kft12 str30 %30s kft12
kft13 str30 %30s kft13
kft14 str30 %30s kft14
kft15 str70 %70s kft15
kft16 byte %10.0g kft16
kft17 byte %10.0g kft17
kft18 byte %10.0g kft18
kft19 byte %10.0g kft19
kft20 byte %10.0g kft20
kft21 byte %10.0g kft21
kft22 byte %10.0g kft22
kft23 byte %10.0g kft23
kft24 byte %10.0g kft24
kft25 byte %10.0g kft25
kft26 byte %10.0g kft26
kft27 byte %10.0g kft27
kft28 byte %10.0g kft28
kft29 byte %10.0g kft29


Thank you for the help.
.

[Joe Canner]

Danny,

kft12-kft15 are strings and all of the rest of the variable are numeric (byte). This is considered a type mismatch.

Regards,
Joe

[DannyBulls]

Dear Joe,

for this dataset, only kft12-15 have a text. Other observations are "." .
Are you suggesting to change STATA's definition of missing values?

Thanks.

D.

[Joe Canner]

Danny,

The "." refers to a missing value not an actual string containing a period. Even when missing these variables (kft1-kft11 and kft16-kft29) are still numeric. If you want to make them strings you can use the string() function or the decode command.

Regards,
Joe

[Nick Cox]

Danny: Joe is right and Stata is right. It looks at variable types when making a check, and they must be all string or all numeric. The fact that real(".") has a simple numeric interpretation is good news in the eye of the beholder but not material at this point.

[DannyBulls]

Hello,
thank you both.
So I decided to use the cmd. tostring just for the kft* variables. Is this a correct solution?

Thank you again.

[Nick Cox]

Is tostring a correct solution?

I can't say, but I have a story. Some years ago I wrote the first version of destring because I needed it, and made it public. Then one day I was remembering a principle that if a reverse transformation makes sense, it should be provided, so I wrote tostring for the fun of it. Then bizarrely Stata tech support wrote asking if I had such a program in my files, because people were asking for the equivalent. Skip to the present, when both have been rewritten heavily by StataCorp and are official commands, but I am still often not sure why people want to use tostring.

Let me try a better answer. Making all your kft* variables the same, all numeric or all string, is necessary and sufficient for a reshape, as you have discovered. But which is better depends entirely on what you want to do the reshaped kft downstream of the reshape. If you want to treat it numerically, you can then destring. Assuming your application of tostring was careful, you will have lost no information.