|
|  |
[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]
st: Re: install updates [was: predict after glm]
Many thanks to Yulia for her help and her detailed description of the
problem and its solution.
Thomas
Monday, 27 Mar 2006 Thomas Gschwend <[email protected]>
asked about a problem he had reproducing a -glm- example in the Stata 9
manual:
> I tried to replicate the glm postestimation example using the beetle.dta
> closely following the code presented in the Stata9 Reference manual A-J on
> page 424. I have two puzzeling observations.
>
> 1) the glm model (without the -quitely- option) prompts a warning message:
> "convergence not achieved" which does not occur when in addition
-, irls- is
> specified.
> 2)-predict- and -mfx- yield the following error message: "Unknown function
> /()"
> ...
This is a follow-up to my previous response on Monday, 27 March 2006. During
my private correspondence with Thomas we were able to track down his problem.
Although he was using Stata 9, Thomas had an old version of a Stata 8.2
UPDATES directory in his adopath. This caused Stata 9 to see the older
Stata 8.2 versions of some ado-files in UPDATES rather than the newer
Stata 9 versions in BASE.
Simply updating Stata in this situation was not sufficient since
-update- replaces only those ado files in the UPDATES folder
that have been changed since the last update of the current Stata version
running. Therefore, in Thomas's case, instead of using the latest
ado-files located in BASE directory, Stata 9 was using the older Stata
8.2 versions of those files from UPDATES folder.
The solution for Thomas was to move or delete the old UPDATES folder from the
current ado directory used by Stata 9. Type
. adopath
to see the whole path, locate the UPDATES folder in your operating system,
and remove it. Then type
. update ado
A new UPDATES folder containing only those ado-files that were modified
during the current version of Stata will be created.
How could something like this happen?
In Thomas's case this was most likely caused by installing Stata 9 on top of
his old Stata 8 installation folder. It is better and safer to always install
Stata to a new empty directory. The Stata 8 uninstaller only removes those
files that it 'knows' it installed. It does not remove any other files that
may have been placed in the installation directory after installation. It
does not know whether such files might be updates installed by Stata or
perhaps user-written ado-files or even datasets mistakenly stored under the
Stata installation directory. For safety, nothing that was not originally
installed is uninstalled.
The more general issue here, however, is what ado-files Stata uses and how
it finds them. The first question may be answered by using the -which-
command. Type
. which filename.ado
to see the version of the current .ado file used by Stata as well as where
this file is located. The answer to the second question lies in the order in
which paths are listed by -adopath-. Stata starts looking from the top-most
path and stops when it find the first occurence of the particular ado-file.
In Thomas's case -adopath- and -which- on one of the files revealed:
. adopath
[1] (UPDATES) "X:\stata_se\ado\updates/"
[2] (BASE) "X:\stata_se\ado\base/"
[3] (SITE) "X:\stata_se\ado\site/"
[4] "."
[5] (PERSONAL) "c:\ado\personal/"
[6] (PLUS) "c:\ado\stbplus/"
[7] (OLDPLACE) "c:\ado/"
and
. which mlopts.ado, all
X:\stata_se\ado\updates\m\mlopts.ado
*! version 7.1.1 23oct2003
X:\stata_se\ado\base\m\mlopts.ado
*! version 7.1.3 27feb2005
Note the -all- option on -which-. This tells Stata to list all instances
it finds of the named file along the ado-path, not just the first one.
We can see that the version number of the file in BASE is _greater_
than the version number of the file in UPDATES. This is how we can
tell there is a problem. The version number in UPDATES should never
be less than the version number in BASE.
In this case using -which- helped to track down Thomas's problem. If
one experiences some odd behavior of the command or gets unexpected
error messages one of the first things one can check is
1) whether Stata has been updated properly, in particular, typing
. update all
. update swap
2) whether Stata is using the latest available .ado files.
-- Yulia
[email protected]
*
* For searches and help try:
* http://www.stata.com/support/faqs/res/findit.html
* http://www.stata.com/support/statalist/faq
* http://www.ats.ucla.edu/stat/stata/
*
* For searches and help try:
* http://www.stata.com/support/faqs/res/findit.html
* http://www.stata.com/support/statalist/faq
* http://www.ats.ucla.edu/stat/stata/
