How to load data from Octave?
Show older comments
I have a .M file from Octave that I want to run in MATLAB, but I obtain an error. Here is the content of .M file (it's just one line):
load "Slovenia_centered.mat"
And here is the error:
Error using load
Unable to read file '"Slovenia_centered.mat"': Invalid argument.
Error in
Slovenia_centered (line 1)
load "Slovenia_centered.mat"
^^^^
5 Comments
Andiswa
on 27 Feb 2026
Use single quote
dpb
on 27 Feb 2026
Don't quote at all in command style
In command syntax single quotes are generally optional, but would be required if the filename (or other input) contained any space characters. This is explained in the documentation of command syntax as well as in the LOAD documentation which clearly states for command syntax "If any input includes spaces, enclose it in single quotes." Lets try it now, where we want to load data from a file named "test XXX" (the .mat is implicit):
XXX = 'hello world';
YYY = 'Wrong File!';
save test XXX YYY
YYY = 'Correct file!';
save 'test XXX' YYY
clearvars
For what it is worth, the LS command uses the same single quotes when required:
ls
Now lets try to LOAD the data from the desired file "test XXX":
load test XXX YYY
YYY
load 'test XXX' YYY
YYY
Rik
on 2 Apr 2026
Adding one related comment:
It is good practice (for both Matlab and Octave) to use the function syntax and load to a variable:
S=load("Slovenia_centered.mat");
Now the variables in the mat file will be fields of the struct S. That way you can keep track of where your variables came from and you don't have any issues with load overwriting variables you were using.
dpb
on 2 Apr 2026
While the function syntax is more general and makes for more generic coding practice, in this particular case OP has another application that uses the command syntax with the specific variable names defined in other code to go with that app.
Accepted Answer
d=dir('Slovenia_centered.mat')
type Slovenia_centered.mat
Aha! It's text, not native .mat.
x=load('-ascii','Slovenia_centered.mat')
To write data from Octave to be imported into MATLAB, it would be more portable to either explicitly write text data with fprintf or whatever other higher-level functions Octave has implemented in parallel with MATLAB or as native binary data with fwrite to read with fopen and fread
Although, presuming Octave has it implemented, if it can write a specific version of a .mat file that has the benefit of also storing the variables and shape and type information that alternate forms don't without extra effort. Just have to be sure to write in a known version and then verify it does work as expected (not that I have any reason to think it wouldn't; Octave has been around for a long time).
91 Comments
I moved to continue the same thread -- dpb
That depends on how the data were written...let's see what the file actually contains...
%type Slovenia
Slovenia
whos
Well, we have an array and the others that were created from them. OK, now see what was mentioned in the comment...
Presuming you know a prior the variable names to use, then you can more directly convert to a table from the 2D array as
vnames={'Dataslcobs','Dataslinobs','Dataslmobs','Dataslpiobs','Dataslrobs'};
tData=array2table(temp,'VariableNames',vnames);
head(tData)
However, here's no reason to make/have two copies of the same data; if you have a (again text) .mat file that is the variables as a single array, then you can read it into the table directly as
fn='OctaveArrayDataFile.mat'; % assume text file
tData=readtable(fn,'FileType','text','VariableNames',vnames);
where like with load have to tell MATLAB a .mat file is in text format rather than native form and it is again required to know the variable names to use (and in which order they are in the 2D array) from prior knowledge
You can then apply all the power of MATLAB to the table referencing each by name with whatever it is that is wanted to be done.
The underlying Q? is how are you getting these .mat files -- are you creating them yourself or is somebody providing them? Can you (or they) change how they're being written to save as -V7 MATLAB .mat files in which case you'll get the variable names and sizes automagically?
What specifically is to be done might aid in other more specific recommenations.
Svit
on 15 Feb 2026
"I think I can't use command fn='OctaveArrayDataFile.mat';,"
Yeah, I forgot that one can't name variables in the readtable function call.
" I need the temp variable, that contains the 5 variables,..."
But, there's a problem here in that the file is just one list of values -- how was the temp array constructed--by knowing a priori that the file is supposed to contain exactly five variables, I presume?
I had thought when you showed that m-file that the file had been arranged such that the temp array was being read as the 2D array and so the file itself had five columns. Unless there are other files, that isn't true and so the previous assumptions all are in error.
d=dir('S*cent*.mat'); % get a dir() for the file(s)
fn=d.name; % the name without having to type long name <vbg>
load('-ascii',fn)
whos
So, what is obtained after the load is, indeed, just one long vector so
try
assert(mod(Slovenia_centered,5)==0) % make sure is divisible by 5
catch
error('Vector length (%d) not compatible; unable reshape to 5 variables. Aborting.', ...
numel(Slovenia_centered))
end
Slovenia_centered=reshape(Slovenia_centered,[],5); % reshape to 2D presuming are 5 variables
whos
In this case, there actually are 109 rows of 5 elements each, not precisely 500 as the prior code produced. You'll have to decide which 9 are immaterial to throw away or keep them all; we have no way to know. NOTA BENE: the above just reshapes the same variable in place, doing away with the temp arrray and includes a check that the vector length is divisible by 5.
You already have the code to create separately named variables from the array given you know what names you want. With the 1D vector of just numeric values, there really isn't any more effective way to take the next step. One ugly coding way that is not recommended to "poof" variables into the workspace is eval, but as the following shows, that's ugly and very error prone and difficult to debug as well as being slow---but that said,
vnames={'Dataslcobs','Dataslinobs','Dataslmobs','Dataslpiobs','Dataslrobs'};
for i=1:numel(vnames)
cmd=sprintf('%s=Slovenia_centered(:,i);',vnames{i}); % make a command to execute
eval(cmd); % and evaluate the string
end
whos D* % see who we made
return % just in here so online "run" won't error on next lines
As noted before, if you would use the option in Octave to write a compatible -V7 .mat file, then you could load exactly what you have in Octave into MATLAB as the five variables as those named variables in the one load command. But, as is, the variable names aren't in the file and it's just a 1D text vector.
% OCTAVE CODE snippet...
Dataslrobs=center(Dataslrobs);
...
save -V7 Slovenia_centered.mat Dataslcobs Dataslinobs Dataslmobs Dataslrobs Dataslpiobs
should do the trick presuming Octave really does implement the MATLAB -mat file correctly. Then just
% MATLAB code
load Slovenia_centered.mat
should give you back the five variables. I haven't had an install of Octave in 20 years so can't test locally, but it's supposed to work.
The other Q? then becomes, if you have access to MATLAB to read these files, why are you creating them with Octave instead of MATLAB to begin with? MATLAB can do everything Octave can do without the hassle. You might have to fix a few syntax errors if somebody used some of the Octave peculiarities that MATLAB doesn't, but it shouldn't be bad.
There's nothing preventing you from just using the existing script to read the vector and manually create the five specific variables from the array. Given the way the present Octave script is writing it as a 1D text array without headers, that's about the best that can be done if you aren't going to change the way Octave writes the data (or just forget Octave and do it in MATLAB to begin with).
Stephen23
on 15 Feb 2026
"I created the .MAT file from existing Slovenia.m file using Octave's commands for demeaning (deducting means) for all 5 variables: Dataslrobs=center(Dataslrobs) (repeating this five times for all 5 variables) and then "save -ascii Slovenia_centered.mat Dataslcobs Dataslinobs Dataslmobs Dataslrobs Dataslpiobs" in order to save the result"
Then why not save yourself all of this trouble by saving using the option -V7 ?
Converting your data to text and back again is a superfluous indirection. Use a binary file format!
Svit
on 18 Feb 2026
If you require that single quote after the integer:
'Vector length (%d'') not compatible; unable mae to 5 variables. Aborting.'
% ^^
Otherwise:
'Vector length (%d) not compatible; unable mae to 5 variables. Aborting.'
Problem with trying to edit inline in the forum without syntax checking in place...changed horses in mid-stream about adding the message in the assert call to separate catch clause and didn't catch all the fixups needed including the dangling quote.
What I really intended was something more on the order of
error('Vector length (%d) not compatible; unable reshape to 5 variables. Aborting.', ...
numel(Slovenia_centered))
There was also a leftover ",5"" from the initial mod() operation pasted in plus a typo in the error message text itself.
"...now I plan to use MATLAB only."
You'll probably find that a good decision in the long run.
I'll note in doing so that earlier you mentioned "demeaning (deducting means) for all 5 variables: Dataslrobs=center(Dataslrobs) (repeating this five times for all 5 variables) ".. Note that in MATLAB (and Octave, too, for that matter) virtually all builtin functions operate by column so it isn't necessary to either loop or duplicate variable names in such a fashion; it's a general sign of not using the vector ability of MATLAB effectively. Instead, use arrays and if need to identify columns in the array, use the table or named fields in a structure; these can be easily manipulated programmatically with direct code to address them rather than having to use contorted features such as eval or duplicate code lines multiple times to operate on the data. Although MATLAB does not explicitly incorporate the center function, it uses
s_c=detrend(s,0); % remove best 0-order trend (mean) from array s by column
The above is identical to
s_c=s=mean(s);
and, of course, if the mean isn't of interest, one can always just replace the original data in place and if wanted, keep the means in another array.
m=mean(s); % compute means of s
s=s-m; % remove means, keeping their values if want later
Of course, one could add their own(*) center function via a user m-file or via an anonymous function...
center=@(a)a-mean(a); % anon function center
although one can't support the optional dim argument that way.
(*) As a personal use pattern, besides a default Work directory I create an Utilities folder in which I keep such generally useful functions that aren't (yet) built into MATLAB. I permanently add these two folers at the top of the MATLAB path so anything in Work, then Utilities is called first.
If I have a specific piece of work for a given client or job, I create its own folder and have a pattern for setting a work environment that will save the current default path and then move to the other environment incorporating any other specific pieces needed for it. These uniformly also rely on the Utilites being available. I can then use the optional input parameter with a value of 'quit' to exit that location and return to the base Work location. That has been most helpful working model to keep things localized but have a common toolset available regardless.
You need to double-check on me, too...in that code the numel() call to get the length is missing......
Slovenia_centered=randn(545,1);
assert(mod(numel(Slovenia_centered),5)==0)
disp('Done')
Runs w/o throwing error...
You've copied all the example code inserted just to show what was in the file as well as the actual code to do the work -- including the 'return' line that I commented that was there only so the subsequent example line of code to use in Octave to save the data from it i(Octave) as the five separate variables you had in it.
There's no code in what you ran that will save the ..mat file in MATLAB to then be able to read it.
You have to decide what it is that you're actually trying to do -- read the original Octave-written ASCII formatted file and create the five variables that we started with or build the data in MATLAB to begin with or precisely what are you trying to do now?
As @Stephen23 and I have both noted, if you were to change the save statement in Octave that created the existing file(s) to use -v7 instead of -ascii then you could just load that file in MATLAB and have the same variables by name in MATLAB directly without any other code being needed. But, if you continue to write files in the same way, then you need the code to create the variables the way you want them instead as one long vector. But, then, if you want to create a new .mat file you'll have to SAVE those in MATLAB; it won't somehow magically change the existing file.
The point is, you have to decide what is your objective here from what starting point and write code specific to those aims. You have to decide that; we can't do that for you.
Svit
on 22 Feb 2026
We've already done that -- as first response showed, all you need to to is to load the file as -ascii instead of trying to read it as a binary .mat file.
The latter code works as well that generates the named variables from the variable name strings if you wnt to use that form instead.
The problem in the last code is that you tried to reread the .mat file yet again....it appears you're trying to do everything by simply copying from somebody else rather than actually reading and understanding the code.
ADDENDUM
NOTA BENE: If you ran the line of code
% OCTAVE CODE snippet...
...
save -V7 Slovenia_centered.mat Dataslcobs Dataslinobs Dataslmobs Dataslrobs Dataslpiobs
in MATLAB after the creation of the D* varaiables, you will have created a new .mat file in the -V7 format that is NOT ASCII any longer but in the native -V7 mat-file format. In that case, you can't read the new .mat file with the -ascii parameter but just with either the same -V7 parameter or without any parameter at all and you will retrieve the five variables as the separate variables.
That would also be true if you did do the same in Octave -- then the .mat file would be in the MATLAB .mat form and have the specific variables saved individually with their names.
in either of those cases, all you would need to do is write
load Slovenia_centered % load native MATLAB .mat file named Slovenia_centered.mat
This is, of course, much simpler and more direct to get the data you want as desired as @Stephen23 and I kept pointing out.
type Slovenia.m
Well, certainly pasting in data manually into an m-file isn't "the MATLAB way". I don't see what is the issue that has you stymied, but starting with the Octave-generated (I presume?) file, the prior code works just fine...
fn='Slovenia_centered.mat'; % set the file name -- change as needed for other files
load('-ascii',fn) % assume was written with -ascii switch in Octave so is vector
% the loaded variable will be the same as the name of the .mat file, "Slovenia_centered"
%whos
try % make sure can split into five variables
assert(mod(numel(Slovenia_centered),5)==0)
catch
error('Vector length (%d) not compatible; unable reshape to 5 variables. Aborting.', ...
numel(Slovenia_centered))
end
Slovenia_centered=reshape(Slovenia_centered,[],5); % reshape to 2D presuming are 5 variables
vnames={'Dataslcobs','Dataslinobs','Dataslmobs','Dataslpiobs','Dataslrobs'};
for i=1:numel(vnames)
cmd=sprintf('%s=Slovenia_centered(:,i);',vnames{i}); % make a command to execute
eval(cmd); % and evaluate the string
end
clear Slovenia_centered % remove the vector copy -- no need to keep two copies of same data
At this point you will have the five D* variables by the names given in the vnames list -- change it to correct any typos or make other desired/needed changes, if any were ever required. The code does presume and require that the size of the imported data vector be evenly divisible by 5; if that were to ever change, the appropriate changes would be required in the testing code and the names array to match.
Above you wrote "I assume the obtained data in 5 columns is now saved in file Slovenia_centered.mat, right?"
The answer to that is a resounding "NO!". Rearranging the data in memory has nothing to do with changing the format or arrangement of the data in the disk file.
As noted in the prior comment, IF you were to save the data now into a .mat file, you could write it that way, yes. But, having done so, then you don't need (and can't use) this code to read the -ascii version. That would not be a bad thing if this has need of being done more than once, but you would then have to be sure to use the right code for the job. There isn't a specific builtin function in MATLAB to query the internal form of a .mat file, but one can query the content of variable(s) in the file using the whos command with the -file argument to find out if the D* variables are there or not and choose which code to run based on that...
% save the specific D* variables in native MATLAB .mat file
save Slovenia_centered.mat Dataslcobs Dataslinobs Dataslmobs Dataslrobs Dataslpiobs
The above replaces the original .mat file in ASCII vector format with the native binary format and keeps the five variables separate.
dir *.mat % see what is there -- is same file name as before
v=whos('-file',fn,'D*') % query the file content of variabless beginning with "D"
and we see there really are five of them as expected.
So, we could write code something like(*)
if numel(whos('-file',fn,'D*'))==5 % see if we have five D* variables in the file
load fn % if so, load them directly
else
% the above code to read the Octave -ascii version and create the D*
% variables would go in here...as well as the |save| command so that only
% do it when starting with the -ascii version.
end
(*) The above checks if the file contains fiive (5) variables whos names start with "D". An alternative way would be to just try to read the file as -ascii as was originally and trap the error and then presume is the desired format...
try % presume is the -ascii version first
% the above code to read the Octave -ascii version and create the D*
% variables would go in here...as well as the save command so that only
% do it when starting with the -ascii version.
catch
load(fn) % if not, assume can load them directly
end
it's in the eye of the beholder which to use...
ADDENDUM SECOND:
Of course, the neat way to code this would be to encapsulate the work to read the -ascii version in a function -- that hides the dirty details from the top level code...
function [Dataslcobs Dataslinobs Dataslmobs Dataslpiobs Dataslrobs] = readASCIImat(fn)
% read Octave-generated ASCII .mat file as vector and return five specific variables
% USAGE
% [Dataslcobs Dataslinobs Dataslmobs Dataslpiobs Dataslrobs] = readASCIImat(file)
load('-ascii',fn) % assume was written with -ascii switch in Octave so is vector
try % make sure can split into five variables
assert(mod(numel(Slovenia_centered),5)==0)
catch
error('Vector length (%d) not compatible; unable reshape to 5 variables. Aborting.', ...
numel(Slovenia_centered))
end
Slovenia_centered=reshape(Slovenia_centered,[],5); % reshape to 2D presuming are 5 variables
vnames={'Dataslcobs','Dataslinobs','Dataslmobs','Dataslpiobs','Dataslrobs'};
for i=1:numel(vnames)
cmd=sprintf('%s=Slovenia_centered(:,i);',vnames{i}); % make a command to execute
eval(cmd); % and evaluate the string
end
% save the specific D* variables in native MATLAB .mat file
save Slovenia_centered.mat Dataslcobs Dataslinobs Dataslmobs Dataslrobs Dataslpiobs
end
Then the above logic in your main program would look like
fn='Slovenia_centered.mat'; % set the file name -- change as needed for other files
try % presume is the -ascii version first
[Dataslcobs Dataslinobs Dataslmobs Dataslpiobs Dataslrobs] = readASCIImat(fn);
disp(['Reading -ASCII .mat file ' fn])
catch
disp(['Loading native .mat file ' fn])
load(fn) % if not, assume can load them directly
end
% Have the specific five D* variables in memory now
% Just to show it does what want, we'll make into a table so can use head()
% conveniently to show resutls...this is only for show, not necessary
% unless you find a use for the table as well...
tS=table(Dataslcobs,Dataslinobs,Dataslmobs,Dataslpiobs,Dataslrobs);
head(tS,5)
% Whatever else you need to do comes next goes after...
Now, let's do this again and see what happens...
try % presume is the -ascii version first
[Dataslcobs Dataslinobs Dataslmobs Dataslpiobs Dataslrobs] = readASCIImat(fn);
disp(['Reading -ASCII .mat file ' fn])
catch
disp(['Loading native .mat file ' fn])
load(fn) % if not, assume can load them directly
end
tS=table(Dataslcobs,Dataslinobs,Dataslmobs,Dataslpiobs,Dataslrobs);
head(tS,5)
We see it read the -ascii file the first pass as started with a copy of the original posted file. The second time it read the rewritten native format file instead since the first past rewrote it. Note that the disp() call is after the attempt to read the file so the error occurred trying to read as ascii so the catch clause was entered before reaching the disp() call.
dpb
on 24 Feb 2026
ADDENDUM THIRD:
function [Dataslcobs Dataslinobs Dataslmobs Dataslpiobs Dataslrobs] = readASCIImat(fn)
% read Octave-generated ASCII .mat file as vector and return five specific variables
% USAGE
% [Dataslcobs Dataslinobs Dataslmobs Dataslpiobs Dataslrobs] = readASCIImat(file)
load('-ascii',fn) % assume was written with -ascii switch in Octave so is vector
try % make sure can split into five variables
assert(mod(numel(Slovenia_centered),5)==0)
catch
error('Vector length (%d) not compatible; unable reshape to 5 variables. Aborting.', ...
numel(Slovenia_centered))
end
Slovenia_centered=reshape(Slovenia_centered,[],5); % reshape to 2D presuming are 5 variables
vnames={'Dataslcobs','Dataslinobs','Dataslmobs','Dataslpiobs','Dataslrobs'};
for i=1:numel(vnames)
cmd=sprintf('%s=Slovenia_centered(:,i);',vnames{i}); % make a command to execute
eval(cmd); % and evaluate the string
end
% save the specific D* variables in native MATLAB .mat file
save Slovenia_centered.mat Dataslcobs Dataslinobs Dataslmobs Dataslrobs Dataslpiobs
end
NOTA BENE: The above works only for fn being specifically 'Slovenia_centered.mat' and for the specific save statement as written in Octave such that the variable name on loading the file is the same as the name of the file itself (sans extension, of course). To handle other file names one would have to use the variable assignment of load such that the data are returned in a struct and the name of the variable is a field name in the struct that could then be referred to programmatically rather than as a fixed variable name as in the above code.
Stephen23
on 26 Mar 2026
"Could I simply change the name order in line:"
Yes, that should work.
Also note that by far the simplest and most robust solution is to specify an actual .MAT format when calling SAVE in Octave.
Svit
on 27 Mar 2026
What is the order you think the variables are in, specifically? List them in that order in the vnames array.
Then set a breakpoint in the function after the loop and ensure that is, indeed the order desired. If not, rearrange as needed.
Note that the line
save Slovenia_centered.mat Dataslcobs Dataslinobs Dataslmobs Dataslrobs Dataslpiobs
rewrites a MATLAB .mat file of those variables that will contain the individual variables and only need
load Slovenia_centered
to get them back.
Also note that the calling of the function has to have the variables named in the right order as is in the function statement line
function [Dataslcobs Dataslinobs Dataslmobs Dataslpiobs Dataslrobs] = readASCIImat(fn)
If you call it with a vector of variable names in another order, that will reassign in the order as given in the function returned argument list. If you want that to be in a different order, then you can rearrange those as want...it's the problem of using a bunch of similarly-named variables by name instead of a more generic data structure like an array or struct; it's easy to get things fouled up.
[Tom Dick Harry Ted Alice] = readASCIImat(fn);
will rename everything; be sure you use the right variablel names in the right order.
Again, as @Stephen23 and I have been saying from the beginning, fix the Octave code to use the -V7 parameter when saving and all this will go away.
Svit
on 28 Mar 2026
"I did use your -V7 parameter: save -V7 Slovenia_centered.mat Dataslpiobs Dataslinobs Dataslcobs Dataslrobs Dataslmobs"
Finally! Saving the data in a proper .mat file is by far the best approach.
Once you have saved the file correctly using the -V7 flag please upload it here by clicking the paperclip button.
"Error: Function definitions are not supported in this context. Functions can only be created as local or nested functions in code files."
AFAIK Octave, just like MATLAB, does not permit functions to be defined like that in the command window. The error message shows that you attempted to create a function in the command window, thus the error. Solution: do not attempt to create functions in the command window (which is also exactly what the error message tells you).
"The data is in order PI IN C R M and names of variables are in order C IN M PI R."
Where did those variable names come from all of a sudden? Those aren't the ones mentioned anywhere prior?
save -V7 Slovenia_centered.mat Dataslpiobs Dataslinobs Dataslcobs Dataslrobs Dataslmobs
The above (presuming Octave isn't broken) will have written a native MATLAB .mat file in the V7 form which will contain the above variables in a binary form internally as well as the information about the variable names, data types sizes, etc., etc., ... All you then should do in MATLAB is write
load Slovenia_centered
and they will, like magic appear in the workspace by those names identically as were in Octave. Note you don't even have to provide the ".mat" extension, load will do that transparently for you although it's ok to do so, it's just a minor convenience/shortcut if typing.
">> function [Dataslpiobs Dataslinobs Dataslcobs Dataslrobs Dataslmobs] = readASCIImat(fn)
returns an error:"
We can't see where you tried to do that from here, but the function readASCIImat must be either in its own m-file with the file name readASCIImat.m or as an internal function in some other script or function file. You've got code structure wrong somehow but we can't see your file/workspace to be able to know precisely how.
However, if you really did save the file in Octave using the above syntax, then it will NOT be an ASCII text file at all any more (the whole point of doing so) and the function to read the ASCII-file form of the .mat file is not needed any more nor can it be used because it won't be able to read the binary -V7 form of the file as text because it isn't text any more (again that being the whole point of using "-V7").
SIDE COMMENT
"I did use your -V7 parameter:"
NOTA BENE: It is neither "mine" (nor @Stephen23's), it's a value for the MATLAB /Octave mat-file version parameter to set which version of a .mat file to write. See the documentation for <save> for MATLAB and the equivalent page in Octave for details.
While still in Octave after having done the above, type
whos -file Slovenia_centered
and show us the output.
The last file you attached is still the ASCII text file format so it is NOT the file that the above command would have created (unless Octave is broken). Be sure you're actually looking at the correct file in MATLAB--do the same command as above in MATLALB and you should see the same result. (Note that if the file is NOT a native .mat format, (is still ascii text) the above will fail that isn't a valid .MAT file).
You have to provide enoguh context somebody can figure out what is going on ... isolated code lines alone simply aren't sufficient context. You started this whole thread trying to LOAD a .mat file written from Octave in MATLAB but that was written as -ascii, not in .mat form. We solved that by reading the file as text and creating the named variables that it contained from it but pointed out the far simpler way to the end result would be to write the file in Octave as a native .mar format file instead, in which case you could then solve that original problem as the initial try was -- by using LOAD directly.
So, what happened to that?
As for all the above, for the most part we can't tell where you did what -- if the SAVE statement didn't work in Octave(*) then the specific variable wasn't defined at the time. Whether the name was misspelled ot ihe variable had accdentlally been deleted or for whatever cause we have no way to be able to tell out of context; but whatever was the reason, it didn't exist as was requested in the SAVE command. Whatever caused it, it would be a totally different issue from the SAVE statement itself; probably attributatble to "pilot error". We would have to have the whole session interaction in context to be able to say anything about the exact cause.
As for the WHOS command, I suggested to do it in both environments to prove first had written the file correctly in Octave and then to prove were referencing the same file in MATLAB (and that Octave did write a readable .mat file.).
(*) NOTA BENE: Recall at least one version of my function to read the ASCII form of the file created the .mat file from the returned variables read from the original -ascii SAVEd file you attached. If you ran that, then you well may be looking at that result instead of a file written by Octave -- we simply cannot tell for sure because you didn't show the context of any of the commands and we can't see your terminal from here. If that were to be the case, be certain to have straightened out the variable names order issue. The solution if you didn't do it that way would be to remove that .mat file and then create a new -V7 version in Octave. Of course, the cleanest solution of all since you now have MATLAB would be to move the Octave m-files all over to MATLAB and do it all there and not have to deal with Octave at all.
Going back to the beginning --
Your original Q? was
"I have a .M file from Octave that I want to run in MATLAB, but I obtain an error. Here is the content of .M file (it's just one line):
load "Slovenia_centered.mat"
So, now you have the .mat file such that that line will work -- if you remove the superfluous apostriphes leaving
load Slovenia_centered.mat
since in the command format the filename will already be interpreted as text and in that form the apostrophes would be interpreted as text and look like part of the filename. It would appear from the outside that should again be the content of the m-file.
Svit
on 31 Mar 2026
Stephen23
on 31 Mar 2026
Replace
save -ascii
with
save -V7
or any other actual Matfile version.
dpb
on 31 Mar 2026
Svit
on 1 Apr 2026
So, what specifically do you think is wrong now?
No errors, no data, no attached file, no ...
I don't know if Octave implemented it or not, but as suggested before, you could/should try
whos -file Slovenia_centered.mat
first in Octave (if it is implemented to read the created .mat file, it should reflect the contents in the file), then in MATLAB. Presuming Octave isn't broken and can write a valid .mat file, it will also show the content of the .mat file.
Of course, you need to be absolutely certain you're looking at the same file in both locations and not different files of the same name.
Svit
on 1 Apr 2026
@Svit: the .MAT standard make no claim about the order of the variables, and nor should you (that would be a bug in your code). The order listed there is purely an artifact of their WHOS display routines, and makes no absolutely difference to the correctness of the values (assuming that Octave wrote the file correctly) stored in the files. That is the whole point of the .MAT file.
Do you have a specific example (code, not just you writing more text) of any of wrong values actually being returned with the wrong name? So far you do not.
Lets make it very simple. Here are the first nine values of Dataslpiobs:
format long G
S = load('Slovenia_centered.mat')
S.Dataslpiobs(1:9)
How do those values compare against the ones that you see in Octave? They should match exactly.
whos -file Slovenia_centered
load Slovenia_centered
whos
and you see that the LOAD statement returned all those variables by name to the workspace. (Note the difference between this command line syntax and the function syntax used by @Stephen23--the command line form returns the variables in the .mat file directly to the workspace in which the LOAD command is executed whereas the functional form returns the variables in a struct where the fieldnames are those of the variables.)
To then further amplify on what @Stephen23 shows--in the beginning you said the m-file contained only the single line to load the .mat file -- ergo, the external app must be expecting the various variables by name -- and it will use the variable name(s), not their positional location in some particular order in which are chosen to be listed.
You're making an issue out of something that isn't -- the only case in which the order will matter is IFF you use the Octave default which is the -ascii form, THEN if you try to create the named variables from the single vector, it will matter as to the order in which Octave wrote them out. It's a bad system because if it doesn't write them out in the order listed, there's no information in that file that tells you in which order they were written. If that old code vnames array is in the wrong order in defining them, then that will be the root cause and even more reason to use the MATLAB binary .mat file format.
"How could I check if the file is the same? "
One of several ways, the most straightforward would be to delete all prior versions and then recreate one and only one. Otherwise, compare filenames and location -- Windows won't allow two files of the same name in the same folder. Or, of course, compare sizes and dates.
Svit
on 2 Apr 2026
whos -file Slovenia_centered % see what is in the file and that is valid .mat file
load Slovenia_centered % load the variables into workspace
whos % see what we got
Dataslpiobs(1:5)
Then the file you're LOADing is not the same file as the one you've posted here....or something else has been done besides.
As stated before, if one of those old Octave -ascii files is still hanging around and you've run the previous code on it, the issue of variable names order is pertinent and at least one version of it would have created a local MATLAB .mat file of that content. As we've both said numerous times, be sure there aren't ANY of those old files around anywhere to be found.
It wuuldn't hurt to create a -V7 .mat file in Octave with a totally unique file name (but same variables, of course) and then LOAD it to prove it.
"... can I ask questions about Dynare on this forum as well ...?"
You could ask (the forum won't prevent off topic questions), but the likelihood of somebody here also being knowlegeable is probably quite small -- and even if they are expert, it still would be off topic and a candidate for an editor to flag or close.
If it is about something specific regarding the use of MATLAB itself with the product, there's a chance, but otherwise I would expect your best bet will be the product-specific forum(s).
dpb
on 2 Apr 2026
"I created new file in Octave and opened it in MATLAB ..."
I would strongly suggest you find and remove the bad originally-named one so it doesn't continue to haunt...
Svit
on 2 Apr 2026
Svit
on 25 Apr 2026 at 10:57
Stephen23
on 25 Apr 2026 at 15:33
@Svit: for this reason (and others) it is recommended to always LOAD into an output variable:
S = load(..)
The output variable is a scalar structure which contains one field for each loaded variable: when you look at that structure, you will see that the .mat file does not contain a variable named "Slovenia_centered2". Clearly it is only possible to LOAD data that actually exists.
The MATLAB script you are trying to run is, like the previous, expecting to have a specific set of variables in it -- to use the scripts as written you will need to use the variable names that are expected by the script.
As shown before, use
whos -file Slovenia_centered2.mat
at the command line and you'll see the content -- which will undoubtedly, match the expected names in the script.
The name of the file is immaterial to the content within the file -- for consistency and ease, and to keep track of what is what, it would be much wiser to keep the same file-naming convention the originator of the ocde used as long as you're just duplicating prior work rather than creating something new-- simply insert the "-V7" parameter when writing it and then it will work as the previous to LOAD and again, you won't need all the cruft of reassimbling a bunch of variables from the one long vector; Octave will have SAVEd the variables as they were and MATLAB will LOAD them in just as they were created in Octave -- just like the prior case.
While @Stephen23 is correct in his observation of using the functional form of the LOAD statement for generic programming, you're using script(s) and an external package that are written to have the individual specific variables.(+)
You must learn enough about Octave and MATLAB to understand the basics to use them rather than simply trying to blindly copy something you've gotten from somewhere else.
(+) If all were being done in Octave or you used the native Octave text file format instead of a native MATLAB .mat file format, then the LOAD would again retrieve the one long vector and MATLAB would again fail as in the very beginning without the "-ascii" parameter. The accomplishment of the previous exercise was to get rid of that complicating and unnecessary step by writing the data in a MATLAB native binary transfer format instead.
@Svit -- Insert the code as code -- use the Code icon to format it as code.
Comments --
%function result=booti(vecdate);
% booti.m: Estimates a New Keynesian model with capital formation and nominal
% frictions. Standard errors are computed by making use of a bootstrap
% procedure as outlined in Cho/Moreno (2006) and Ireland (2007).
%
% Program is written by Oke Röhe (2010)
%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Housekeeping
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
clear
"clear" serves no good purpose in a function which has its own workspace. In the above code, it will clear the input argument so vecdate won't be defined when and if the code ever tries to use it. Remove that.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% 1) load data (c(t),i(t) and m(t) are HP-filtered (but remeaned -> see Dave&Dejong, 2007)
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
global ct it mt pt rt bigt scalinv
load Slovenia_centered2.mat;
ct = Slovenia_centered2(:,1);
it = Slovenia_centered2(:,2);
mt = Slovenia_centered2(:,3);
pt = Slovenia_centered2(:,4);
rt = Slovenia_centered2(:,5);
Here you again have Octave-style code trying to use as MATLAB code without paying attention to what the code is actually doing. You created the variables in the .mat file -- just load them; the variable Slovenia_centered2 doesn't exist in the function.
The above should be just
load Slovenia_centered2.mat
assuming the file wanted is the above and the file was written as a "real" MATLAB .mat file. If so, the variables will appear. This should be becoming a well known mantra for you by now. And, again, there's no relationship between a file name and the content of the file itself.= -- it's all what it was named and what variables were written to it.
The far better way to write the function would be to pass in the filename when calling it instead of having it hardcoded in the function so have to edit the function to change it.
As for the optimset error, the requested option, 'LargeScale' is as the error says, not a MATLAB option but something specific to the Octave implementation. There is no equivalent in MATLAB, remove it to make the code accept the statement. What effect it had in Octave and whether it works in MATLAB is to be discovered; you'll have to research the difference(s) in what Octave implements vis a vis MATLAB for that.
As for the error about no permissions, that's something we can't tell anything about -- looks like an OS permissions thing.
As I've noted before; this would undoubtedly be far easier to just run somebody else's code in Octave if you're not going to move it all to MATLAB. It would seem a fair amount of value might be added to build a robust MATLAB version for the community as part of the output of your work; the exisitng code has many things that could be improved such as the details noted above. OTOH, if the goal is only to reproduce prior work or just compute numbers for some slightly different set of inputs, then just use the code as you were given it and go on.
Svit
on 27 Apr 2026 at 8:55
Setting a link to the file isn't working in the forum this morning; it showed the link but dir() returned nothing. Not sure about what's going on there, but it's a problem in the forum unrelated to your issues.
So, I downloaded the file and locally I find --
>> whos -file Slovenia_centered2
Name Size Bytes Class Attributes
ct 109x1 872 double global
it 109x1 872 double global
mt 109x1 872 double global
pt 109x1 872 double global
rt 109x1 872 double global
>> load Slovenia_centered2
>> whos
Name Size Bytes Class Attributes
ct 109x1 872 double global
it 109x1 872 double global
mt 109x1 872 double global
pt 109x1 872 double global
rt 109x1 872 double global
>>
If you had done the above experiment as I suggested, you would have already discovered/proved that the file does contain the various variables and LOAD retrieves them so simply using it is all that should be in the secondary code, albeit I still think hard-coding the filename in the function is poor practice, that, too, is only style and inconvenience to be able to use more than one file without editing the code.
But, it does show you do need to get rid of all the other stuff and just use the variables -- again, that was the whole point in saving as a native MATLAB .mat file to begin with.
Beyond that, things are going to be dependent upon just what the differences are between Octave and MATLAB in the optimization routines used compared to MATLAB. We akready addressed at least one issue in an Octave-specific optimset parameter not available in MATLAB(*). You'll just have to use the Octave documentation in comparison with MATLAB to figure out anything else there. And, of course, it would be imperative to first run the original code in Octave or have prior output to confirm are getting the same results.
As for formatting the actual code, paste the text in, select it and press the code button or use the shortcut Ctrl-E.
Regarding the use of the functional form of the LOAD statement, read the documentation for <load>, it returns the data as a MATLAB struct; the fieldnames of which are the names of the variables. As I've noted multiple times before, that works well for generic coding but the code you were given would have to be modified to use the returned struct form instead and, since the .mat file contains the variables as expected directly, there's no advantage to be gained here. Again, you need to read and study the documentation carefullly and learn enough of the basic language syntax to understand what you're doing instead of just randomly trying stuff. There are examples of using both in the documentation; you need to look at those and experiment enough at the command line or with a breakpoint set in the code until you can understand the syntax/usage.
(*) ADDENDUM/ERRATUM
Actually, optimset does return an options struct that does have the 'LargeScale' field; something else appears to have happened to have created that error earlier -- even though I couldn't find the parameter in the current online documentation and thus came to the wrong conclusion regarding the error message.
ADDENDUM SECOND
In running the function I noticed something overlooked before -- the function statement has been commented out of the file so it isn't actually a function at that point but another script -- hence, apparently, the insertion of the clear, clc lines by whoever/whenever did that. In that case, it's a bludgeon that will destroy everything in the workspace including any other work may have wanted...it's a bludgeon and rarely needed either way. It will be better code factoring to again turn it into the function (adding an 'end' statement at the bottom) to keep local variables local and avoid other side effects.
As earlier this AM, trying to run in the forum fails because the attached link isn't found -- that's a forum problem.
--dpb
booti
So, I downloaded booti and under R2022b
>> booti
Unrecognized function or variable 'llfn'.
Error in fminunc (line 307)
f = feval(funfcn{3},x,varargin{:});
Error in booti (line 87)
[thetstar,fstar,exitflag] = fminunc(@llfn,bigtheto,options);
>>
There's a missing target optimization function llfn.m that will have to have.
Interestingly, the missing optimset parameter that failed with your release and here in the forum does exist in R2022b. Dunno about that difference OTOMH, either, would have to go digging through release notes to see if is mentioned anywhere; it's one I've not run across before so don't know anything about it, specifically.
Stephen23
on 28 Apr 2026 at 4:52
"...there's no advantage to be gained here"
An explicit output argument is a good habit which can be applied uniformly:
- No surprise overwrites: bare LOAD silently replaces any existing variables with the same names,
- Avoids the risk of stale variables being used from the workspace without warning,
- No magic variables: the editor/mlint won't flag x as undefined, because it can see where it came from,
- Allows easy runtime introspection via FIELDNAMES or ISFIELD,
- Self-documenting,
- Goes hand-in-hand with other good practices, e.g. providing the full path via FULLFILE, etc.
Svit
on 30 Apr 2026 at 11:54
I showed the results of that above, yes.
load Slovenia_centered2
whos
If you used the previous file, then should have no issue unless there's a clear in the function afterwards or you're using a different file ...
As the error message shows, don't have the optimization function.here.
NOTA BENE: converted back to a function by
- Uncommenting function line and
- Adding "end" at end of file
- Removed a bunch of extra blank lines as personal preference to shorten code in editor significantly -- immaterial other than visual.
booti
function result=booti(vecdate);
% booti.m: Estimates a New Keynesian model with capital formation and nominal
% frictions. Standard errors are computed by making use of a bootstrap
% procedure as outlined in Cho/Moreno (2006) and Ireland (2007).
%
% Program is written by Oke Röhe (2010)
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% 1) load data (c(t),i(t) and m(t) are HP-filtered (but remeaned -> see Dave&Dejong, 2007)
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
global ct it mt pt rt bigt scalinv
load Slovenia_centered2
bigt = length(ct);
trend = 1:bigt;
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% 2) set starting values
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
...
Above is how I would write the beginning of the function.
Removed rest of code for brevity in forum -- dpb
Well, just cleaning it up some runs into the same issue here...the optimization function is still LLFN and isn't available.
The other errors are something you've done in your environment outside the given code....that we've no way to know anything about since we can't see your terminal from here.
The attached code is again a script, not a function so it will be running in the command workspace and so what else you have in variables or other loaded tools beyond the basic MATLAB Mathworks-supplied ones is unknown. That's a situation where a CLEAR might be needed; the more robust way would be to use functions to isolate things to their own workspace.
Of course, you could have done this yourself instead of expecting somebody else to ...
ADDENDUM
which -all run
NOTA BENE that RUN is a very ubiquitous and important builtin MATLAB function -- particularly the part in the base language 'lang' dictionary. Don't use such names for your scripts/functions; that may well have a lot to do with the other errors you're getting. Make a name that is unique and representative of what the script/function does; rename the file to it and then delete any local copy and try again.
% run.m: Model: Sticky price model of the business cycle similar to the
% setting developed in Ireland (2003).
%
% Randomly-chosen starting values are used to find the
% maximum of the model's likelihood function.
%
% Output:
% startingval
% paramvec
% likeval
% errormat
% sevecstarmat
%
% Country: France
%
% O. Roehe (2010)
global ct it mt pt rt bigt scalinv
N1=2500; % define program constants as data, don' put data in line in code
N2=20;
load Slovenia_centered2
bigt = length(ct);
trend = 1:bigt;
fstarmat = zeros(N1,1); % Contains the log-likelihood values for
tostarmat = zeros(N2,N1); % Contains the transformed starting values
tstarmat = tostarmat; % Contains the paramerter estimates
flagmat = fstarmat ; % Saves MATLAB error messages
%Generating starting Values (transformed parameters)
for t0 = 1:N1
t0
% omega_mu, omega_pi, omega_y, sigma_a, sigma_e,
% Sigma_x, sigma_z, and sigma_v
thetoscale = [ 1 60 1 3 0 0.001 0.001 0.1 0.1 0.001].'; % use .' for matrix transpose, not complex
% set size of initial estimates based on size of number variables
theto = rand(size(thetoscale)); % Generating starting values for gamma, phi_P,
theto = thetoscale.*theto;
betatr = 0.1094;
gammatr = sqrt(theto(1)/(1-theto(1)));
alphatr = 0.29;
etatr = 1.5;
thetatr = 5;
gtr = 0;
deltatr = sqrt(0.025/0.975);
phiptr = theto(2)/100;
phiktr = 0.35;
mutr = 0.009;
omegamtr = theto(3);
omegaptr = theto(4);
omegaytr = theto(5);
etr = 4.4423; % Set to match with re-meaned HP-filtered data (See DeJong and Dave, 2007)
ztr = 0.4242; % Set to match with re-meaned HP-filtered data (See DeJong and Dave, 2007)
rhoatr = sqrt(0.9/0.1)/10;
rhoetr = sqrt(0.9/0.1)/10;
rhoxtr = sqrt(0.9/0.1)/10;
rhoztr = sqrt(0.9/0.1)/10;
rhovtr = sqrt(0.9/0.1)/10;
sigatr = theto(6);
sigetr = theto(7);
sigxtr = theto(8);
sigztr = theto(9);
sigvtr = theto(10);
% Maximizes the (minimizes the negative)log likelihood function for the model
bigtheto = [betatr gammatr ...
phiptr phiktr ...
mutr omegamtr omegaptr omegaytr ...
etr ztr ...
rhoatr rhoetr rhoxtr rhoztr rhovtr ...
sigatr sigetr sigxtr sigztr sigvtr].';
startingval(:,t0) = bigtheto;
%save startingval startingval
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Chose between optimization algorithms to maximize the objective function:
% a) fminunc (MATLAB)
% or
% b) csminwel (Chris Sims)
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% a) fminunc - find the minimum of an unconstrained multivariable function
% (derivative based)
options=optimset('Display','iter','LargeScale','off','MaxFunEvals',10000,'MaxIter',10000);
[thetstar,fstar,exitflag] = fminunc(@llfn,bigtheto,options);
...elided remainder of code for brevity -- dpb ...
end
Svit
on 1 May 2026 at 7:19
- Rename "run.m" to something that doesn't conflict with MATLAB builtin functions.
- Nobody else can run anything without the missing optimization function
- Debugging without any symptoms is impossible, you'll have to delve into the problem to see what goes wrong and why -- that's research although the error about a singular matrix is perhaps instructive as noted before.
- The code comments indicate it used a different technique in Octave than the MATLAB fminunc routine; have you used that instead? I would guess "run" is also a builtin function in Octave, too, that should not be aliased.
And, @Svit will need to understand enough about the problem trying to solve to be able to determine if the functional is even feasible as specified...such issues are generally at the heart of such minimization problems. fminunc is an unconstrained solver; it's possible a set of conditions is being generated that causes the unknown LLFN function to fail with over- or underflow numerically or create NaN or Inf or such.
However, it would seem until can get the original to work and reproduce previous author's results in Octave, the transition to MATLAB would be premature. I've found a lot of papers by Dr. Oke Röhe including roughly the right tme frame and appear to be same topic but no links to code.
That's the nub of the problem; the code is just a tool...
It may not have solved the problems you are having, but aliasing the builtin run function cannot be good.
As for the rest, what does "crash" mean, exactly? You've given no error messages or any other hints, even.
There's nothing else to be done here without the LLFN function that is the objective of the optimization routine.
Your statement above " can run the files perfectly. In MATLAB, his file with French data crashes after one hour, the same as my file with Slovenian data." is unclear as to its actual meaning. If, indeed, the good doctor is getting differening results for the identical code (do you actually know for sure the code he sent is what was run; the date of 2010 is quite a long time ago), you might want to axk about what versions of MATLAB and Octave he was using. It would not be out of the realm of possibility that changes since then make a difference.
The warning about the singular matrix is again a clue that the system is likely linearly dependent in two or more estimators -- as noted, use the debugger and see what is going on to cause that; there's a good chance it's a similar issue in MATLAB as hypothesized before with the optimization function evaluations -- be we don't have the function.
"Prior to crash, thousands of errors "Matrix is singular" appear"
Well, DOH! Didn't you think that odd and worth investigating after the first one? Not terribly surprising it eventually will crash in that case although technically, MATLAB should be able to shut down gracefully.
" will ask dr. Röhe for the LLFN function "
If you are running for an hour without the function LLFN, then the code you're running is NOT the code you have posted. I've shown multiple times the results of that exercise -- it gets to the first call to fminunc and dies because the function llfn isn't available in the code you've posted. If you're running that code, it has to be somewhere or that isn't the code being run.
What does
which -all llfn
return?
From before --
...
options=optimset('Display','iter','LargeScale','off','MaxFunEvals',10000,'MaxIter',10000);
[thetstar,fstar,exitflag] = fminunc(@llfn,bigtheto,options);
...elided remainder of code for brevity -- dpb ...
end
The output was as follows...
t0 = 1
Unrecognized function or variable 'llfn'.
Error in objfunEvaluator (line 5)
fval = feval(Objfun, x, self.FunArgs.AdditionalParameters{:});
Error in OptimFunctions/objectiveFirstEval (line 655)
[fval, grad, hess] = self.ObjectiveFunAndGrad(self,self.FunFcn{3},...
Error in fminunc (line 135)
[f,GRAD,HESS,funObj] = funObj.objectiveFirstEval(x);
You need to read the code instead of continuting to just blindly try to copy and paste in others' work. The line
[thetstar,fstar,exitflag] = fminunc(@llfn,bigtheto,options);
is wehre all the heavy lifting is being done -- and the @llfn is a <function handle> to the function being evaluated for a minimum as denoted by the "@" in front of the function name.
"Yes, in 2025 ..."
You might ask what his ver command returns and compare to yours -- have you installed any available patches/updates? It also is an outside possibility it could be OS dependent, would want to check on that as well just for comparing environments.
However, the most likely issue will be one that the optimization function is not returning expected results -- whether the problem structure isn't correct or the function itself is in error or for whatever the reason turns out to be, there's more than likely where the issue will be found to be.
But, need to first confirm which specific code is actually being run and then delve into what is causing the symptom -- and that can only be done at the low level of seeing just what is happening the very first pass, not by just waiting and hoping magic will occur and it will heal itself. As noted before you'll have to understand enough about the problem you're trying to solve to be able to determine what the optimization function is supposed to return.
As knew, the function had to be available.
The task is to test it to find out what is causing the singular matrix result. Certainly nobody here can do anything without it.
There would normally be a robo-generated acknowledgement to a suppoort submission followed up by a later response. I don't know that Mathworks will think it's their responsibility to debug your code, however; the issues that lead to the crash after a sequence would appear to be either bad input or a badly-formed optimization function. They can find what did cause the code to eventually crash, but that is not going to solve your numerical issues that got to that point after an hour.
You need to start by evaluating the output of LLFN to the initial conditions and work on from there.
ADDENDUM
I'd still have questions about whether the code/data you're using are actually that which ran 15 years ago....would need a set of inputs including the starting point estimates which are probably not reproducible since they're randomly generated and there's no code to set a specific seed for the RNG and it's not likely those were saved to be able to retrieve. Failing that, a new run that does work with sufficient detail to reproduce identically would be helpful although one could start with a specific set of inputs to the optimization function and its output to ensure it matches.
Failing something along those lines, you'll simply have to read the papers to understand the methodology well enough to be able to figure out where the solution goes bad....whether the model matrices are incorrect or just bad data or what. Nobody here is going to be able to answer those questions and the forum isn't a free general consulting service and relying on such for a research dissertation wouldn't be exactly kosher, either.
We can help solve specific issues regarding the use of MATLAB and, to some extent Octave, such as the Q? of how to get the data from the Octave file into MATLAB, but it's beyond the scope to dig as deep as it appears this is going to take; particularly when the underlying code is not well commented as to what it is actually doing/tryiing to do -- that could only be determined in detail by reading the papers and none that I saw that appeared to be same/similar problem in the time frame used the specific formulation for solution in your code and as you've noted, the code doesn't appear to be publicly available with such background documentation.
Svit
on 4 May 2026 at 16:49
But have you even tried to run the optimization function LLFN with your set of inputs to see if it returns a reasonable result?
"...need a set of inputs including the starting point estimates which are probably not reproducible since they're randomly generated and there's no code to set a specific seed for the RNG and it's not likely those were saved to be able to retrieve. "
Actually,
save startingval startingval
does save the starting values for each pass through the loop -- did the code/data you were supplied also contain a startingval.mat file? If so, you do have some values to test/compare to. Also, if Dr Rohe supplied them, there are other intermediary output files as well. Of course, if you didn't save the originals, you're trying will have overwritten them.
Or set a breakpoint after the call to fminunc and looked at the return values -- particularly the exitflag rather? Do your part first.
Svit
on 4 May 2026 at 18:02
>> llfn
Not enough input arguments.
Error in llfn (line 29)
bigthet = real(bigthet);
You have to pass it the expected argument array of starting values...read the code!!! Of course, depending upon how it was written and upon what it depends, it may have to be in a context where the global variables are accessible, too.
The breakpoint is waiting to execute the line; there are no output arguments defined yet...but you can inspect the inputs expected by llfn and use those to execute the function at the command line -- or, of course, also set a breakpoint in LLFN to see what's going on inside it. (You'll note my suggestion was to set the breakpoint on the line AFTERI so it would have run one minimization case; the point being to see what the minimization routine exit flag returned -- that would tell you quickly if it failed or thought it succeeded.)
It should return a reasonable MLE value; whether log(MLE) or not I don't know without the code/comments(*), but clearly should return a finite positive value in order to be able to minimize with respect to the variables....
(*) While no promises, and if you had any expectations of anybody in the forum doing anything further, having the LLFN function code would be essential.
Svit
on 7 May 2026 at 10:02
"I apologize, but I am competely lost. LLFN.M file is attached. Could you explain me how to enter startng values?"
Once I comment out your inadvisable modification LLFM is trivial to call (without error):
V = rand(1,20);
llfn(V)
Instead of random values you would pass your values, exactly as dpb stated. Its output should make sense.
"Do you mean writing line "load Slovenia_centered2" before line"
No. I do not see that advice anywhere in dpb's comments.
As @Stephen23 says, leave the LLFN source file identically as you received it. As I suspected, it also requires the global variables as well as the starting values computed before the call to fminunc that uses it (the llfn function). Hence, the simplest way is as I suggested, set the breakpoint and then at the command line while stopped, enter
llfn(bigtheto)
since at that point both the starting estimate values and the global variables will be in scope.
Of course, as also suggested, step one line past and see what the return values from fminunc are after the first call as well.
You simply must spend some time learing rudimentary MATLAB syntax and use to have any hope of being able to use this toolset for your research purposes. Start at least by working your way through the "Getting Started" section and read the documentation and examples for common features like function and the background information on <Functions>. Without any understanding at all of scope, arguments, return values, etc., ... not only will your efforts be extremely slow and ineffective, you won't even be able to communicate with those who might help without a basic knowledge of what terms mean.
Note as I mentioned before that the code writes out those starting estimates every pass through the loop and that if by any chance Dr Roehe included those .mat files in the information he sent you (and you had the foresight to preserve his originals) then you would have a set of starting values that were supposed to be those that actually ran the supplied code for testing and comparison with what the present code is generating that doesn't seem to be working. But, simply starting and determining what are getting now is a start...
NOTA BENE:
V = rand(1,20);
llfn(V)
the function ran without error but returned an empty [] result.
That is owing to running it in an environment where the global variables have not previously been defined and are in scope and so they're all empty -- but being global variables makes then still be visible. If you were to comment out the global line, then the function would fail for whichever of the variables were to be the first one referenced.
That's why the doc page for <global> notes they are both expensive and dangerous and should generally be avoided. Their use in this code set certainly contributes to its difficulty in use and debugging although it would take some effort to recast the code to not use them. But, they certainly contribute to the fragility of the code as written.
The evaluation code computes starting values from scratch and then saves them before each iteration so they can be retrieved later -- it doesn't read them in, but you can inspect them to see how they compare to what your code is generating. The issue there is, of course, whether you have the original file or are looking at the output of yours that overwrites the file each time it is run. Again, "READ THE CODE!!!" to understand what it does and how it is constructed -- you will see there is no correspnding LOAD for those SAVEd files, only the one that reads in the previously-computed global variables. You can do a search for "load" to make it easier to be sure don't miss anything. Don't jump to conclusions; be certain of what is being done.
If you read the code for LLFN, you will see the input argument bigthet, the array of starting values is assigned to a bunch of local variables but only bigthet(1) through bigthet(20) are used -- ergo, there are only 20 of them(*). Everything else is local internal stuff used in getting to the end result.
So, if your model contains more variables than those 20 over which it is trying to find a minimum, that would certainly explain the ending result of the singular matrix of results it's running into later -- the difference between the total number and the 20 defined would be set of columns of (probably) zeros.
If your model has more than the 20 estimators that Dr Roehe's code solves for, you'll have to build the additional pieces needed for it -- but the code you've been given knows nothing about any more than 20.
(*) You could pass as big an array as you wanted to the function outside of fminunc but it would ignore all except the first 20. In the optimization routine <fminunc> function, it determines the number of variables to be used in the minimization function calculation from the number of elements in the starting estimates so that would matter -- passing fewer than 20 would fail because one or more would be missing to LLFN, passing more would wreak havoc because it would be trying to estimate a larger model than the MLE function knows anything about so there would be redundant variables which would then also lead to the problem of the output model being linearly dependent. But, Dr. Roehe's code was written specifically for whatever are his 20. It would certainly not hurt to read the doc for fminunc and experiment with one of its examples to understand how it works so you have a better understanding of what this code is attempting. That would seem to be self-evident advice, but ...
Svit
on 8 May 2026 at 11:12
What was the final cause of the crash is not going to solve anything; the sympoms appeared the very first time through the code with the indication of there being a singular matrix. Even iif it hadn't crashed, the result would stil have been a singular matrix; not a solution to the problem.
The point about reproducing the prior results is what I've been trying to get you to recognize you needed to have done from the beginning; that's where having his starting point .mat file will be useful (again, if you still have the original copy he sent and not the one your running the code will have overwritten) to
- Use the values of the first column of that array as bigtheto into LLFN
- In a command session after loading the global variables, call
- llfn(bigtheto)
That should produce a reasonable value (and the same value as his run if available) for the optimization function and should be able to find out where things fall apart in the next step.
I have no idea what/who Dynare is/are, but anybody with MATLAB should be able to reproduce the same result given the same data/code. I can't help but think despite protestations to the contrary that there is something different; figuring out precisely whether it's data or code is the trick.
I don't recall at the moment whether his code also saved the intermediary functional result for each iteration or not but there's the key comparison -- need to be certain are computing the same loss function value for the same inputs. Of course, also need to be sure the values of the global variables you've computed also match since LLFN is also dependent upon them.
You keep trying to get all the way to the end instead of looking at the beginning first and working methodically through each computational step in sequence.
- The singular matrix on its own didn't, but it's immaterial to the basic problem that per your prior comment the algorithm/data is returning a set of values from each minimization iteration that then results in the singular matrix. That's the root problem; there would not be a singular matrix if the minimization routine were producing expected results -- what it's indicating to you is that there's something wrong there very early causing the problem; you need to find out what is causing that to happen; when you discover that you'll have the answer. And then, it is almost certain whatever is the eventual crash will also not occur. You and those folks are letting the crash distract focus from the real problem; it's a red herring. If you don't understand what the matrix being singular means, see the following <simply written overview> that should let you at least get a grasp on the problem. Again, what is the specific cause here is yet to be uncovered, but it's the real issue, not MATLAB having finally thrown up its hands and saying "I quit!"
- Refer to the doc for function again and function arguments. Look up "function argument association" -- it's what makes functions such a valuable programming construct. And, also re-review how fminunc works.
- Read the evaluation code -- as I've said multiple times and is clear from the code, it saves those starting values for each iteration by column. Doesn't the "2500" ring any bells when you look at the evaluation code? You don't seem to be really looking at and associating what it must mean and relating that to things like what the file content must be and how to interpret it.
As I noted before, I don't recall otomh whether his code is also saving the individual return values from each iteration, but that would be useful if so as well...you should be able to use the same starting estimates and then reproduce the same outputs identically to within machine precision(*). If that doesn't happen (and, from the symptoms, it's almost certain it won't), then you've got the starting point of where to dig isolated. I'm guessing the resulting minimization results are going to be all zero or some such for at least a couple of the variables because something isn't formulated as it is expected to be and that would be the cause of the ill-condiditoned matrix.
There's also a set of fixup lines at the end of the LLFN function that store a very large number if something unexpected happens -- it may be that's what is happening instead and then multiple columns could be essentially indistinguishable because they're all that very big number. We/you simply don't know until you look at what's happening in the beginning in detail. That's what have been tryhing to get you do do in the debugger -- run the LLFN function with a known set of inputs and see what it returns...I'm expecting it won't be what you/the code are/is expecting it to be. if that were to be true, I don't know whether that would be owing to data or something not right in the code you have compared to what has worked, but you've got to figure out where it breaks and how, specifically, first. Waiting until it eventually crashes and then trying to do a postmortem isn't goiing to be a productive debugging scheme as you've already found out.
(*) If the SAVEd .mat starting values were saved in MATLAB binary format so are full machine precision; if they're in Octave default text, then that precision difference would cause differing results -- that, depending upon the numerics might be sizable.
Svit
on 11 May 2026 at 13:22
I don't know what else you would have done but run from the command line...
But, the warning and singular matrix is still being generated, not a useful result.
NOTA BENE the values of the functional are what I suspected might be the case of ~1E12, the magic fixup number in the LLFN function.
The issue is still to figure out why -- is it an input data issue or some code difference?
As noted before, look at the code and see if it also saved the output results of each iteration to compare from what the good doctor sent you -- and what was the input data and the values of the global variables you calculate versus his. Somewhere something is broken or wrong data; still don't know just what, but something isn't right.
I haven't read the details of the mathematical models thoroughly to follow just exactly what is being done after the minimization step, but there's where the inversion problem crops up...but that's the fatal step; but one presumes it wouldn't have been singular in his cases that worked before. Ergo, one has to conclude either you don't have the actual identical code that was used before or the data are different or some other misstep has occurred along the way to this point.
Svit
on 11 May 2026 at 14:01
"... to run his code again, not my version with Slovenian data but his original code with French data"
That's what you should have been doing all along to find out where things go wrong if doesn't reproduce his results. Again, simply one iteration will be conclusive as to whether it does or does not generate the singular matrix on the step after the minimization.
Again, I can't emphasize enough, you need to look in his code and see what other variables were SAVE'd all of those, presuming he sent you all the .mat files, are the pieces you have to be able to check what is/is not the same. I think it is incumbent upon you to do all that ground work first.
If his original code and data do work and yours still doesn't, then you will have demonstrated that your data are the issue and the model isn't suitable for them, at least as you have them prepared and input to the model. That would then be the crux of your problem to be able to determine what may be significantly different (or not following whatever are the assumptions the model makes about the data). That would be the research aspect of the proposed thesis; I don't believe it would be upon someone else to solve the problem for you in its entirety. One would need to have enough of an understanding or the assumptions of the given model for a specific monetary system to be able to judge whether another economic system follows the same pardigm sufficiently to use the same model. Trying to use this code as a black box is likely not going to ever be successful; estimating 20 variables is no mean feat in even well-behaved systems, empirical modes such as this are even more problematical, particularly when there may be fundamental differences in how alternate economies operate.
And, I'd also strongly recommend to read and study the link I provided about what data singularity implies and the kinds of things that cause it. One (or more) of those things is happening in your case; your task is to determine which one(s) and resolve that underlying problem.
...
% form matrices M and N
[kvec,keig] = eig(bigk);
keig2 = diag(keig);
[keig3,kord] = sort(abs(keig2));
kviol = 0;
if keig3(2) > 1
kviol = 1;
end
if keig3(3) < 1
kviol = 1;
end
...
Just a coding aside...
% the above could be written as
kviol= (keig3(2) > 1) | (keig3(3) < 1); % logical variable
Then at the bottom of the routine is
...
% penalize eigenvalue violations
if kviol
llfn = llfn + 1e12;
end
if abs(imag(llfn)) > 0
llfn = real(llfn) + 1e12;
end
The above is what is going on in LLFN in your example case before -- you need to learn enough about the mathematics behind the methodology to be able to understand what the above is telling you....and how to deal with it.
Note, however, there are two different possible causes for this to happen that can't tell which may have been the cause -- the first is one of two specific eigenvalues is of unexpected magnitude/sign (although they're sorted first so is no guarantee of which is the actual one in the model space) while the other is that an operation generated a complex value which is just arbirarily converted to real and flagged. Any of those in all likelihood is a bad sign that things aren't following the expected patterns for the model.
Again, you'll not get anywhere if simply try to use this code as a black box for any arbitrary economy and/or data set without knowing enough about it to know what its assumptions are and what such pieces as the above imply. I glanced through some of his papers on the subject but none of them used this solution technique; whether it is even applicable to those or your proposed problem I wouldn't know. I would presume somewhere there is a paper in which this technique is introduced.
ADDENDUM
I suggest if you have additional Q? or other pertinent information that might make a difference to start a new Question thread; this one has become so long that the interface has become extremely slow in response. However, as noted, I think we've seen enough hee that the problem isn't one with MATLAB (or Octave for that matter) itself but the data you're trying to use the method on isn't amenable to the particular model attempting to be applied.
Svit
on 12 May 2026 at 18:47
"...I can successfully run the doctor's file with data for France..."
OK, that then does confirm do have consistent set of data and code...first step.
It also then definitively proves the issues are data related in using your data instead -- that could be any number of things as outlined in the white paper reference, but does give you something from which to start.
The comparative economies and thus applicability of the intended analysis is the highest level consideration first followed by whether have consistent measures of the necessary parameters and then the preparation and input of those. Comparing the two input parameter by input parameter would be the immediate next exploratory analysis I would do to see which are similar and which might be totally dissimilar in magnitude and patterns. Evaluation of series length and whether any are highly correlated with each other would be another important check. Without detail examination of those and then comparison of the details of the estimation process, it's not possible to know where things went south, but clearly the data you presented to the model is not compatible with the solution technique at least and may possibly not be amenable to the modelling being attempted at all. Only by digging into the innards will be able to tell...
Yes, I am sure none of the commented-out lines have any bearing whatsoever -- and that putting them back in will put you back to the very beginning question that started this thread two months ago -- that by default an Octave .mat file is NOT a MATLAB .mat file but a single one-column text file. The whole exercise we went through in the beginning was to avoid the mess that original code is in trying to convert the 1D vector back into five separate variables.
We did that by writing the .mat file from Octave by using the "-V7" flag so the ..mat file was written as a native format MATLAB binary .mat file in which all the variables are stored by name and in the identical form as were generated and to full machine precision.
Only if you revert back to the ugly and inefficient text file format does that issue return. There are several example responses I gave before that conclusively demonstrate that LOADing the file you generated reproduced the same numbers; you can prove it to yourself yet again by looking in the debugger. Or, as also noted many times, simply type
whos -file yourmatfilename.mat
at the command line and, if it is the expected/desired .mat file format, it'll show the content...that's been demonstrated before several times, too. Of course, if it is an Octave default file, MATLAB will tell you it isn't a .mat file at all.
How, specifically, you ran the French data instead we don't know, but that was and is the best solution to tranferring data from Octave to MATLAB and is the exactly correct way to do so.
I don't know enough about the mathematics behind the model to be able to comment further on the existence of the sungular matrix but it doesn't seem reasonable to me that proper estimates of model coefficients would be returned if the solution matrix is, indeed singular. Did that run return reasonable results for the model coefficients and reproduce the published results?
That's an off topic subject for the Answers forum as to what the model itself is and predicts, but unless you can reproduce those results from the code and data you don't have the correct solution to the problem. But, I don't have time (nor inclination) to try to dig sufficently into the theory and math behind the model and estimation of coefficients, but can definitively answer the specific MATLAB usage question -- IF the .mat file being LOADed is a MATLAB native format (written either by default from MATLAB or with the "-V7" or other version parameter in Octave), then all that need (and can) do is LOAD the variables in that .mat file. OTOH, if the file is one like the original from Octave, then it is NOT a .mat file at all, really, but the 1D text file and that would only be possible to be LOADed in MATLAB with the "-asciii" parameter (which being missing in the original code was and is a fatal error) and then you are back to trying to reconstruct the variables from the 1D vector. You will simply have to learn enough about using Octave and MATLAB in order to understand what you are actually doing instead of continuing to treat it as if it were a magic black box. Sorry, but we've been over this ground so many times before that it seems futile and pointless to keep re-explaining the identical issues over and over and over.....
I do wish you well in completing your research objectives...
That is probably at least a start; I would again not jump to any conclusions that will be the only issue
You may recall I had suggested you needed to investigate the properties of your data thoroughly quite some time ago as well. <wry grin>.
As to your Q? regarding academics, no, I never did a dissertation nor entered a formal PhD track -- life intervened requiring a salary first...did finish a MS Physics (Nuclear Science) while working and continued taking course work for 20+ years after BS off and on so had probably double the credit hours would have needed. Writing the thesis while working with young family was enough of a challenge in the days of mainframes before personal computers and word processing beyond the IBM Selectric.
More Answers (1)
dpb
on 13 Feb 2026
load "Slovenia_centered.mat"
Using the command syntax the filename is text already so it's including the apostrophes as well...try
load Slovenia_centered.mat
I'm not sure about what level for .mat file compatibility Octave supports, you may need to check there about ensuring .mat files.
4 Comments
Yes. The documentation explains why using double quotes will fail with command syntax, it has whole section entitled "Why Does Using Command Form With Strings Return An Error?":
The gist of it is "In command form, double quotes are treated as part of the literal text rather than as the string construction operator". This is to be consistent with how command syntax has always worked.
dpb
on 13 Feb 2026
BTW, to complete the picture
load("Slovenia_centered.mat")
will also work because as an argument the "" are constructors and the underlying char string will be passed.
Stephen23
on 13 Feb 2026
According to the Octave SAVE documentation
its default is to "Save the data in Octave’s text data format. (default)." Apparently it also has options to save in formats which are MATLAB compatible.
Andiswa
on 27 Feb 2026
Use single quote
Categories
Find more on Octave in Help Center and File Exchange
