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.
댓글 수: 7
" 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 signature (and the typical and more proper way of using functions) of passing the input data in as a dummy argument 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 intended 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
2026년 5월 20일 13:34
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.
Indeed, if only were communicating with the orginal author...or the poster showed any inclination at all to try to improve the packaging of the code to be more robust and user-friendly, even if only for his/her own usage.
I suggested way back nearly two months ago in the prior (seemingly almost interminable) thread that a major benefit of his thesis work would be such a result for that community; potentially far more valuable than the analysis being attempted.
"what other input files are there for test.m! I think it's only est.m?"
"It (est.m) is, as the extension suggests, another m-file, and is 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."
In MATLAB (or Octave), m-files contain code, either scripts or functions and, while will be required to be available if referenced, they are NOT inputs. It's fundamental that user-written functions are essentially no different than Mathworks-supplied builtin functions; a large percentage of which are m-files themselves.
"...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."
That is the same issue as the original question and what was noted above that Octave returns its .mat files as text vectors. MATLAB doesn't work that way.
"...what to do with ... caldq and meancimpr(vecdate,:)."
The latter of those is an array subscripting expression -- unlike previous functions that didn't use the dummy argument vecdate, this one does so...ergo, it will have to have been defined as an actual argument before calling the function and passed or it will be undefined on execution. Also, this code is assuming meancimpr is a 2D array (note the ":" on the second dimension indexing expression), not a linear vector as did that prior code and the various variables again being created from the array by column before. The only thing different from the original question code is the need to reshape() the 1D vector into the 2D array(+). But, this then relives the previous case where having computed those variables before, it would be far simpler if you instead SAVEd a MATLAB .mat file with those variables as was done in the first case, then LOAD them instead; if the name was changed and were SAVEd or written as a 2D text file somewhere, then will have to retrieve from there. The original author understood what he was doing and he took shortcuts in reusing the same code as starting a basis for a number of steps with the same variables being reused for subsequent calculations after having been modified by a previous step. We're back to the problem of you needing to really understand what is being done, not just try to make the code run somehow and by rote copying of one specific fix that solved one issue to other places where that may not be the solution because the circumstances are, while perhaps similar, not identical.
The other appears to be another function using a starting and ending year and month that selects a (sub?)set of an (unknown) array based on year, month of a starting and ending time -- that it is hardcoded means the other data having been used better be consistent over the same time frame and granularity. The comment of 114 observations seems to roughly match quarters being mentioned before since 114/4 = 28.5. NOTA BENE that the actual data being referenced isn't identified by the call--it's another case that the function will either LOAD another array or be using GLOBALs instead of the clean coding method of passing the needed data to the function. It would appear there must be a calds_q.m file somewhere. Yet again, you're back to the problem of needing to really understand what is being done, not just try to make the code run somehow.
As I suspected, the other data file is totally extenally generated; did you add a pertinent comment as to the mystery?
(+) I don't have Octave and don't know its foibles; we discovered that Octave SAVEs multiple variables that are each vectors as a single column text file with the variables catenated into one long file. It may (and probably does) write a 2D array as a 2D text file; hence the assumption above of a 2D array. MATLAB will LOAD a text file without the '-ascii' parameter if (and only if) it doeis not have a .mat extension is why the above LOAD statements will work at all; in the prior code the default .mat file extension for SAVE was used which caused the LOAD statement without the parameter in MATLAB to fail. Again, it appears he learned new tricks as he went along from step to step....
추가 답변 (0개)
카테고리
도움말 센터 및 File Exchange에서 Matrix Indexing에 대해 자세히 알아보기
Translated by 
