Error with the vselect command

[Pinar Uysal]

I have the most upto date Stata and am having trouble using the user written command vselect. I asked a colleague of mine to run the same code, and it runs on his computer perfectly fine. I would like to know what is going on so that I can also run the program.

1- The code is as follows:
sysuse auto
vselect mpg weight trunk length foreign, best

2- The error is:
variable npred not found
st_view(): 3598 Stata returned error
leaps_bounds(): - function returned error
<istmt>: - function returned error

3- The version of vselect is:
c:\ado\plus\v\vselect.ado
*! version 1.2.0 10mar2014

Thank you.

[Nick Cox]

I can't reproduce this either with the last version in the Stata Journal or that on SSC, which is later than either.

Thanks for the testable example, but it helps to know where you got a program, not just that it is user-written.

In this case, and despite what you say, I would worry that your Stata is not properly updated, e.g. that executable and Mata files are not in sync. Show us the result of

 
update query

[Pinar Uysal]

Nick,

Thank you for the quick response. It is my work laptop and I don't have the admin priviledges to update the Stata.Therefore, I asked our IT guys to update it and this morning they downloaded the latest version from:

http://download.stata.com/download/

And I cannot use update query because we are behind a firewall which block access to www.stata.com. When I go to Help=> About Stata => I see "Revision 07 Nov 2014" if this information helps.

I got the vselect command from:

http://fmwww.bc.edu/repec/bocode/v/

Even my-coauthor who has Stata 13.0 can run the vselect command with no errors.

[Nick Cox]

To complete matters as far as possible I report that I have Stata 13.1 and it's bang up-to-date and as said vselect from SSC runs without errors.

[Pinar Uysal]

Thank you. You can find the information about the update status below. Do you have any other suggestions? I can ask for a Stata re-installation but I'm doubtful that it is going to solve this issue because IT has already did a fresh install this morning and I have 13.1 Stata MP.

update all, from("C:\Users\e2pxu01\Downloads\stata13update_win \stata13update_win")
(examining C:\Users\e2pxu01\Downloads\stata13update_win\stata 13update_win)

Update status
Last check for updates: 09 Dec 2014
New update available: none (as of 09 Dec 2014)
Current update level: 07 Nov 2014 (what's new)

Possible actions

Do nothing; all files are up to date.

[Nick Cox]

I would search very carefully for multiple versions of vselect on your system.

[Matthew White]

Perhaps try reinstalling vselect? ssc install vselect from within Stata. What's the checksum of the file? Try:

findfile vselect.ado
checksum "`r(fn)'"

I get:

Checksum for vselect.ado = 2348515916, size = 31355

Other than that, maybe try clear all and clear mata before running your example?

[Emanuele Clemente]

Dear Statalist,

After the latest installation of Stata17 update (14th Nov 2023), I am now facing the same issue reported by Pinar Usyal. I get the error even when using the example commands from the vselect help file.

As per this thread, I have tried clear all, mata clear. When I ran the checksum I got a different result from Matthew. I got: Checksum for c:\ado\plus/v/vselect.ado = 2600710548, size = 31333

Thankful for any other hint/suggestion you may have

[Fahad Mirza]

I thought of giving closure to this long overdue thread.

This is happening because in the ado file of vselect, the variable name is "npred" while the temporary dataset being created has the variable name "npreds".

To solve this, open the ado file in your dofile or any other editor. Once open, search for all occurrences of "npred" and replace them with "npreds".

Then save the ado file and restart Stata.

This would solve the problem.

[Chen Samulsion]

Thank you Fahad Mirza. Given that it is a variable name misspell in ado file, but why Nick Cox runs it without errors?

[Fahad Mirza]

Good question Chen Samulsion, because even when I was using this command a month or so back, it was running perfectly fine until just yesterday it started giving the same error as discussed on this thread. Maybe it is something to do with the "set abbrev" settings and the way Stata is picking variables. Not sure.

However, changing it to npreds from npred, solves the issue.

[Nick Cox]

I think Fahad Mirza is correct. The error is reproducible if, and I think only if, you

set varabbrev off

My attitude to abbreviation of variable names is this. In principle it's a bad or at least questionable idea and I think I should not do it in public; in practice I learned early on, meaning 1991, that Stata lets you do it and I often do it in private.

At any rate, I don't set varabbrev off routinely, which explains why it didn't bite me back in the day.

A similar but not identical detail is abbreviation of command names. I really would not have wanted to type generate not gen however many times I used the command, but whenever I remember I don't abbreviate command names in say help files. (Oddly, the consensus on gen not g or any other abbreviation is socially curious. I guess it's partly a meme often followed and partly defensible as short enough to type quickly and long enough to be clear, or at least clearer than g. I know one experienced Stata user who prefers gene but then again he was a biologist.)

[Fahad Mirza]

Nick Cox I still dont understand one thing though, how come the command worked previously but suddenly stopped working because of this. Even though Stata was not updated and nor was the command. Any thoughts?

[Nick Cox]

"suddenly stopped working" is not a problem report that allows much specific comment. Even for physical devices there is usually a story if only you can find it, such as a battery ran out or something fractured inside.

My only guess is that some code flipped the variable abbreviation convention the other way.

Code is what we live by, or work by, but even very smart people sometimes write very problematic code. Years ago I stumbled across some code that in passing changed the format of all variables whose names began with d to daily date display format. That was in an ado and wasn't even documented as a side-effect of the ado. On querying this I was told, Oh yes, at our workplace we have a rule that daily date variables, and only daily date variables, have names beginning with d. The people concerned were quite unfazed at a comment that it was one thing to have a local convention and quite a different thing to foist that as a rule on other people. I quietly resolved never to use any code produced by that group.

As a comedian said when explaining what was happening in Wagner's Ring cycle, "I am not making this up, you know".

[Andrew Musau]

Oh yes, at our workplace we have a rule that daily date variables, and only daily date variables, have names beginning with d

No one can make this up!