[~,col] = find(ocpRefPt(2,:)>x1 & ocpRefPt(2,:)<x2 & ocpRefPt(1,:)>y1 & ocpRefPt(1,:)<y2);
About is the line where the compilation fails. The above line is in a loop.
x1,x2,x3,x4 are scalars(natural numbers)
ocpRefPt is a 2x16 matrix
Error: FIND requires variable sizing
What does this mean. How to overcome this error?
So it seems that you are trying to compile with emlmex to make embedded code. The error is saying that the size of the output of find is not known, and apparently the compiler requires fixed size outputs. See this newsgroup post for one explanation.
This method of compilation seems to be obsolete -- use the MATLAB coder (codegen command) instead:
emlmex Generate a C-MEX file from MATLAB code.
emlmex [-options] fun1 [fun2 ...]
This function is obsolete. For general purpose acceleration
and code generation use CODEGEN.
Related
It is occasionally convenient to use a function as a "constant" variable of sorts in MATLAB. But when I was using this feature recently, I ran into an unexpected error. When I run the MWE below, I get the error Undefined function or variable 'a'. despite the function being clearly available in the same file. When I comment out the if statement, the error goes away. This seems to imply that MATLAB is pre-interpreting a as a variable even though the variable assignment line is never reached, ignoring the fact that there is a function by the same name. Is this a MATLAB bug or is it somehow the desired behavior?
Here is the MWE:
function matlabBugTest( )
if false
a = 'foo';
end
a
end
function b = a()
b = 'bar';
end
Follow-up:
I know it seems weird to intentionally use the same name for a variable and a function, so I'll give an example of where this can be useful. For instance, you may want to use a function to store some constant (like a file path), but also want to be able to use a different value in case the function cannot be found. Such a case might look like:
if ~exist('pathConstant.m', 'file')
pathConstant = 'C:\some\path';
end
load(fullfile(pathConstant, 'filename.ext'));
I know that language design decisions are often difficult and complicated, but one of the more unfortunate consequences of MATLAB's choice here to ignore the function by the same name is that it breaks compatibility between functions and scripts/command line. For instance, the following runs without issue in a script:
if false
a = 'foo';
end
a
where the function a (shown above) is saved in its own file.
It has to do with how Matlab performs name-binding at compilation time. Because matlabBugTest has a line that assigns a value to a, a is determined to be a variable, and the later line with a is a reference to that variable and not a call to the local function. More modern versions of Matlab, like my R2015a install, gives a more clear error message:
At compilation, "a" was determined to be a variable and this variable is uninitialized. "a" is also a function name and previous versions of MATLAB would have called the
function. However, MATLAB 7 forbids the use of the same name in the same context as both a function and a variable.
It's not so much a bug, as it is an ambiguity introduced by the naming scheme that was given a default resolution method, which can be annoying if you have never encountered the problem before and m-lint doesn't mark it. Similar behavior occurs when variables are poofed into the workspace without initialization beforehand.
So the solution is to either change the name of the function or the variable to different things, which I would argue is good practice anyways.
In considering your follow-up example, I have noticed some interesting behavior in moving things around in the function. Firstly, if the function is either external or nested, you get the behavior discussed very well by Suever's answer. However, if the function is local, you can get around the limitation (at least you can in my R2014b and R2015a installs) by invoking the function prior to converting it to a variable as long as you initialize it or explicitly convert it to a variable at some point. Going through the cases, the following bodies of matlabBugTest perform thusly:
Fails:
a
if false
a = 'foo';
end
a
Runs:
a
if true
a = 'foo';
end
a
Runs:
a = a;
if false % runs with true as well.
a = 'foo';
end
a
I'm not entirely sure why this behavior is the way it is, but apparently the parser handles things differently depending on the scope of the function and the order of what symbols appear and in what contexts.
So assuming this behavior hasn't and will not change you could try something like:
pathConstant = pathConstant;
if ~exist('pathConstant.m', 'file')
pathConstant = 'C:\some\path';
end
load(fullfile(pathConstant, 'filename.ext'));
Though, entirely personal opinion here, I would do something like
pathConstant = getPathConstant();
if ~exist('pathConstant.m', 'file')
pathConstant = 'C:\some\path';
end
load(fullfile(pathConstant, 'filename.ext'));
Concerning breaking "compatibility between functions and scripts/command line", I don't really see this as an issue since those are two entirely different contexts when it comes to Matlab. You cannot define a named function on the command line nor in a script file; therefore, there is no burden on the Matlab JIT to properly and unambiguously determine whether a symbol is a function call or a variable since each line executes sequentially and is not compiled (aside from certain blocks of code the JIT is designed to recognize and optimize like loops in scripts). Now as to why the above juggling of declarations works, I'm not entirely sure since it relies on the Matlab JIT which I know nothing about (nor have I taken a compiler class, so I couldn't even form an academic reason if I wanted).
The reason that you get this behavior is likely that Matlab never have implemented scope resolution for any of their statements. Consider the following code,
(a)
if true
a = 'foo';
end
disp(a)
This would actually display "foo". On the other hand would,
(b)
if false
a = 'foo';
end
disp(a)
give you the error Undefined function or variable "a". So let us consider the following example,
(c,1)
enterStatement = false;
if enterStatement
a = 'foo';
end
disp(a)
(c,2)
enterStatement = mod(0,2);
if enterStatement
a = 'foo';
end
disp(a)
TroyHaskin clearly states the following in his answer
It has to do with how Matlab performs name-binding at compilation time. Because matlabBugTest has a line that assigns a value to a, a is determined to be a variable, and the later line with a is a reference to that variable and not a call to the local function
Matlab does not support constant expressions and does only a limited amout of static code analysis. In fact, if the if statement takes argument false, or if enterStatement is false, Matlab provides a warning, This statement (and possibly following ones) cannot be reached. If enterStatement is set to false Matlab also generates another warning, Variable a is used, but might be unset. However if enterStatement = mod(0,2), so to say if enterStatement calls a function, you get no warning at all. This means that if the example in the question was allowed then (c,2) would compile based on how the function were evaluated and that is a contradiction. This would mean that the code would have to compile based on its runtime results.
Note: Sure it could be good if Matlab could generate an error in case the enterStatement was an expression instead of a constant false, but whether or not this is possible it would depend on implementation I guess.
I have an anonymous function that I would like to manipulate in string form then use with fsolve.
When I do this the references in the anonymous function to constants are lost and fsolve fails.
The problem is easily illustrated.
The following works:
A=3;
myfun=#(x)sin(A*x);
x = fsolve(#(x)myfun(x),[1 4],optimoptions('fsolve','Display','off'))
The following throws an error as explained here:
A=3;
myfun=#(x)sin(A*x);
mystring=func2str(myfun);
%string operations would go here such as strrep(mystring,'A','A^2') or whatever
myfun2=str2func(mystring);
x = fsolve(#(x)myfun2(x),[1 4],optimoptions('fsolve','Display','off'))
Is there some way I CAN safely manipulate an anonymous function while retaining references to constant parameters?
more info
Specifically I'm writing a simple wrapper to allow fsolve to accept imaginary numbers for simple cases. The following illustrates a working example without a constant parameter:
myeqn=#(x)0.5*x^2-5*x+14.5;
cX0=1+1*1i;
f1=strrep(func2str(myeqn),'#(x)','');
f2=strrep((f1),'x','(x(1)+(x(2))*1i)');
f3=strcat('#(x)[real(',f2,'); imag(',f2,')]');
fc=str2func(f3);
opts=optimoptions('fsolve','Display','off');
result=arrayfun(#(cinput)[1 1i]*(real(fsolve(fc,[real(cinput);imag(cinput)],opts))),cX0)
As in the failed example above if I include a parameter in my wrapper the process fails with the same error as above.
I originally suggested to use the symbolic math toolbox, but reading your question again I realized it's just a simple substitution of input parameters. You can achieve this using function handles without any string processing.
myeqn=#(x)0.5*x^2-5*x+14.5;
cX0=1+1*1i;
wrapper=#(x,f)([real(f(x(1)+x(2)*i)),imag(f(x(1)+x(2)*i))])
opts=optimoptions('fsolve','Display','off');
result=arrayfun(#(cinput)[1 1i]*(real(fsolve(#(x)wrapper(x,myeqn),[real(cinput);imag(cinput)],opts))),cX0)
As much as I hate to suggest using the eval function, you could do:
myfun2 = eval(mystring);
Using eval is kinda frowned upon because it makes code hard to analyze (since arbitrary nastiness could be going on in that string), but don't let other people's coding style stop you from doing what works :)
In your longer example, this would correspond to changing the line:
fc=str2func(f3);
to:
fc=eval(f3);
Again, the use of eval is strongly discouraged, so you should consider alternatives to this type of string manipulation of function definitions.
We have very strange error that I don't know why:
This code run with my laptop and is correct but It doesn't work with another
laptop(has the same matlab version) with this error TOO MANY INPUT ARGUMENT
In Line 10!
clear
syms b c d;
E=29000; I=240/144;
mab=2*E*I*(b)/18;
mba=2*E*I*(2*b)/18;
mbc=2*E*I*(2*b+c)/12-24;
mcb=2*E*I*(b+2*c)/12+24;
mbd=2*E*I*(2*b+d-3*.6/144)/12;
mdb=2*E*I*(b+2*d-3*.6/144)/12;
[tetb tetc tetd]=solve(mcb==0,mba+mbc+mbd==0,mdb==0,b,c,d)
c=tetc;
b=tetb;
d=tetd;
eval(mab)
Use which solve to check which function is called. Since they differ in your case (see comments), you can use the method given for this question to exactly specify the path for a function to use. See addpath and rmpath there.
I had a function in a file harmonic.m in my matlab path with prototype:
function D = harmonic(A,B,C)
where, importantly, A is expected to be a matrix of type double.
In version r2014a, apparently MATLAB has created a new builtin class method double.harmonic. Thus when I call my function I get an error inside the wrong harmonic. It doesn't help that my harmonic is closer in the path list (which harmonic reveals my path) because my first input is A and harmonic(A,B,C) seems to be equivalent to A.harmonic(B,C).
Is there any way to call my function directly? To ignore this double.harmonic function? I know I can create a function handle from the path, but that's nasty. I'm looking for a more elegant solution or workaround. The most obvious being change my function's name, but then I'll feel bullied : - (.
Put your version of harmonic into a folder #double, and make sure that your folder #double is above \toolbox\symbolic\symbolic\#double on the path (this new double.harmonic is from Symbolic Toolbox).
That will force your function to become a method of double i.e. it will be double.harmonic, rather than a generic function harmonic. When deciding which thing to dispatch to, MATLAB will consider methods first, then generic functions later. Since your double.harmonic and the other one are both methods, and yours is ahead on the path, yours will win. BAM - eat that, MATLAB!
depfun's documentation gives the following:
[list,builtins,classes] = depfun(fun) returns the MATLAB classes that
fun requires.
Excellent, this is exactly what I want. However, when I call that on my function it tells me there are too many output arguments. So, I tried
list = depfun(Dynamo)
and to my surprise the same error occurred. How can this be? depfun(Dynamo) must return at least one argument, no?
What I'm trying to do is to create a dependency graph in the way as suggested by Andrew Janke in Automatically generating a diagram of function calls in MATLAB
The following works and gives me a nice report, but I don't want the graph to contain all the hidden functions which is why I'm opting for depfun.
profile on
Dynamo;
profile off
profview
Any insight is much appreciated
You need to pass the function argument as a string
>> [list,builtins,classes] = depfun( 'Dynamo' )