Computing the standard errors
显示 更早的评论
Dear all,
for my master's thesis, I have to compute the standard errors of the estimated model parameters using a bootstrap approach. Trying to run the file "booti2.m", I obtain the following error:
>> booti2
Index exceeds the number of array elements. Index must not exceed 19.
Error in llfn (line 61)
sigvtr = bigthet(20);
^^^^^^^^^^^
Error in
fminunc (line 233)
f = feval(funfcn{3},x,varargin{:});
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Error in
booti2 (line 87)
[thetstar,fstar,exitflag] = fminunc(@llfn,bigtheto,options);
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Caused by:
Failure in initial objective function evaluation. FMINUNC cannot continue.
>>
Please note, that before I could run the original "booti.m" file with data for France successfully, while now I can't run neither Slovenian nor French file. Thank you so much! Meancimpr.DAT file is in the folder Searching for Starting Values - Full Sample
5 个评论
Svit
2026-5-17，14:27
Torsten
2026-5-17，14:34
Then use a .zip file in which you include all necessary files.
Svit
2026-5-17，14:45
There are two files named "llfn.m" in the .zip file, one in the folder "Searching for Starting Values - Full Sample", the other in the folder "Computing Bootstrapped Standard Errors - Full Sample".
In one of them, there is a line
sigvtr = bigthet(20);
in the other, this line is missing.
From the error message it is obvious that "llfn" is called with an array "bigthet" with only 19 instead of the necessary 20 elements. So the llfn-version with an expected length of 20 for "bigthet" cannot be used (or bigthet has to be modified before the call to llfn).
采纳的回答
Since LLFN is the objective function of a call to fminunc, I'd refer you back to the documentation and prior discussions we had about how it (fminunc) works to determine the size of the solution vector, and therefore the required dimensions ot the starting estimate and solution vectors in that function.
With @Torsten's observation that there are multiple LLFN m-files apparently for different purposes with the same name, that appears to be the issue.
We don't have any clue about how the original author organized his code, but from there being different folders/directories for the different purposes, it appears you may need to change your working directory to the correct one for the particular task you're after so the files there will be found in preference to others of the same name (see <How MATLAB resolves functions>).. The better solution would have for them to have been named differently so they wouldn't be confused -- and maybe even reflect their purpose? What a novel idea!
This illustrates even more the importance I've noted before of not continuing to treat this code as a black box; you've got to become intimately familiar with what is there and how it is organized and intended to be used.
4 个评论
" I came to a conclusion that file est.m is possibly another input file..."
It (est.m) is, as the extension suggests, another m-file, and is
% EST.M: Function estimates sticky price model of the business cycle
% similar to the setting developed in Ireland (2003).
%
%
% O.Roehe (2011)
function result=est(vecdate);
% load data, select sample, and detrend
global ct it mt pt rt bigt scalinv
load meancimpr.dat;
end
as the first line says, clearly another function....I would again refer you to the documentation and function and <MATLAB>. At a bare minimum at least go through the "Getting Started" and top-level "Programming" sections thoroughly enough to grasp the difference between a function and a data file. A prepared and fully packaged application written in MATLAB might be able to be used as a black box tool but this code is far removed from being that.
This function (est) has, however, like another before been corrupted from what was the original intent (and the typical and more proper way of using functions) of passing the input data in as a vector (vecdata) by loading another data file meancimpr.dat and also what look like the same global variables as previous code used plus a couple more. This is, as noted before, risky because of the behavior of global variables -- they're going to be whatever was left over by those names in the working scope, whether wanted or not or, depending upon the content of the LOADed .dat file, maybe they're being defined in it -- no way to know without much more forensic work.
As for which data set is in a file of any given name, that will depend upon the last code run that wrote/SAVEd a file of that name in the current working directory. Again, reusing the same file names for different purposes is risky; you have no way to keep them straight as to which file contains what. Some function will have SAVEd the file with that name with the particular country's data; but using the same name so isn't disntinguishable from the name. Without using a fully qualified filename (one containing both the name and the specific folder), MATLAB writes in the current working directory and the problem is you probably.are now not in the same working directory as when ran that particular case. Or, another possibility is that for checking purposes you reran the other country and the code silently overwrote the file so now the second country data no longer exists. That's (only one of) the (many) problem(s) with what the original author did and why blindly following that code without making changes to use distnict names that are identifiable as to the file content is so problematical (and, consequently, so confusing for you to know what you've done and where particular results may be)..
Again, find the SAVE commands; there's where whatever is written is done -- I would yet again suggest you set breakpoints and use unique file names that are identifiable instead of continuing to blindly try to run somebody elses's code that you don't understand.
ADDENDUM
NOTA BENE: The text file may not have been written with SAVE -- given the rest of the code, probably was, but not necessarily. Look for the file name to be sure to find it, not just SAVE. If did use SAVE, it will have to have used the '-ascii' parameter in MATLAB, not positive about what Octave behavior is with SAVE with a .txt extension on the file name. We already know it saves its .mat files as 1D text vectors, not 2D.
v=rand(5,1);
save v.txt v
whos -file v.txt
type v.txt
shows that just defining a filename extension as something other than .mat doesn't change the SAVEd file from being a native .mat file in MATLAB.
Moral: If these codes were written for Octave, behavior may not be what is expected if run in MATLAB just as was the issue two months ago in other thread. Only reading the code to see what it actually does will answer the question, and what writes this partciular file isn't in the m-files you've attached--it must be buried in one of those inside the .zip file that I'm not ambitious enough to go dig into.
ADDENDUM SECOND
"...the problem is you probably.are now not in the same working directory ..."
Another possibility is, of course, that this particular .txt file wasn't created by any of these codes at all, but was/is inteded to be created from external data or yet another piece of code...we don't know and can't tell without digging through the the whole morass.
"...Slovenia_centered3 is not required in the code apparently."
Or, maybe the doctor renamed it externally? We have absolutely no way to know what may have been done nor what it is nor its intended purpose, presuming it had/has one.
ADDENDUM
Maybe it was/is supposed to be the one that computes the GLOBAL variables???? Dunno, but it's yet another possibility. Check the list of global variables in it and compare to the est function list that is augmented with a couple of others that weren't in prior code.
Stephen23
18 minutes 前
It is worth noting that good code practices would have avoided a lot of these issues (or made them much easier to debug / track down). Specifically: avoiding GLOBAL variables, LOADing into an output variable, using a proper MAT file format, etc.
更多回答（0 个）
类别
在 帮助中心 和 File Exchange 中查找有关 Data Import and Analysis 的更多信息
Translated by 
