Matlab gives "Struct contents..." err for an operation with a Stan array within a script but can deal with the same array in the command prompt or if debug mode (via step or cont).

Testing a very simple script:

n=100;
beta0t=2;
beta1t=1;
sigmat=1;
x=randn(1,100);
y=beta0t+beta1t*x+randn(1,100);
plot(x,y,'ko')
data = struct('N',n,'x',x,'y',y);                 
fit = stan('file','linreg.stan','data',data);
print(fit);
beta0=fit.sim.samples.beta0;
beta1=fit.sim.samples.beta1;
sigma=fit.sim.samples.sigma;
figure(2)
h=histogram(beta0);
h.Normalization='probability';

Error comes at beta0=fit.sim.samples.beta0 line. The strange thing is Matlab does not complain when I use the same Stan output in the same manner from the command window. It also does not complain if I stop the script and step through or simply hit continue in debug mode. Stopping the script and continuing is an obvious workaround but a very annoying one. Any solution to this issue? Matlab version: R2016b (9.1.0.441655),

[Walter Roberson]

stan does not appear to be a MATLAB provided function ?

[Murat Aydin]

It is not. You are correct that this is a problem in the sense that Matlab does not recognize "fit" as a formal struct matrix. However, it certainly knows how to deal with it as any other struct matrix as long as you are in the command prompt. The err message pops only when the above operation is carried out within a script. In the debug mode, no error message either. That's why I'm thinking there may be a simple solution to this.

[James Tursa]

"...Matlab does not recognize "fit" as a formal struct matrix..."

What does that mean? If it is not a "formal" struct matrix, then what is it exactly? How can we propose a solution without knowing exactly what it is?

[Murat Aydin]

whos fit command shows "StanFit" under class. A struct matrix created under Matlab shows "struct" as the class.

[Murat Aydin]

The bottomline is, all Matlab functions work with that Matrix like they do with any other struct matrix as long as you are in the command window or the debug mode.

[James Tursa]

So you've got a class object variable that behaves differently depending on where/how it is called. Unless we see the class definition code and can test with it, I don't know what we can do to help.

I will throw this out there. It is known that code can behave differently at the command line & in debug mode vs running parsed m-code. Usually it is innocuous but sometimes these differences can cause problems if your code is sensitive to it. E.g., how MATLAB will pass arguments to functions can vary depending on this. Or how MATLAB interprets literal constants can vary depending on this. Maybe something like that is going on in your case ... who knows without us being able to see the code?

[Murat Aydin]

That's exactly what's happening. First time I experienced it in Matlab. Stan is an open source bayesian statistics package that can be run from different interfaces, Matlab being one of them. I think the whole package will be needed to test this. I realize now I'm more likely to find people who ran into the same problem at MatlabStan home instead of here. Thanks for the responses.

Answer 1

[Walter Roberson]

I hypothesize that it uses assignin(), or that you are doing a load() that is "poofing" variables into existence. These days inside a function the Just In Time Compiler prefers to use syntactic scope instead of dynamic scope. For example,

   function foo(x)
      load bar
      myscript
      sin(x)

then JIT will assume that the load is not creating sin and that myscript is not creating sin.

If you have functions that are using assignin() to assign to a variable that might not exist, or if you are using a script to assign to a variable that might not exist, or you are using load() to "poof" a function into existence, or you are using load() to "poof" a variable into existence which has the same name as any function on your MATLAB path -- then assign something (anything) to the variable before calling the magic code, so that JIT knows that the name is going to refer to a variable later.