Thread Subject:

Failure in initial user-supplied objective function evaluation. FSOLVE

I don't understand a word of this error - So I just show you my program.
You need two files:



1) globals.m:
=========================================
global body g bodies numCoords numConstr alpha % only has one line...
=========================================


2) test.m (or whatever):
=========================================
function newGearConstraint2D
clear all;
clc
close all

globals % <--- read the file above (1 line)

body{1}.radius = 0.3; % m
body{2}.radius = 0.15; % m
depth = 0.1; % m
alpha = 20/180*pi; % pressure angle
dt = 0.01; % sec.
Tend = 1; % sec.
%------------------------------
disp(['Gear ratio: ' num2str(body{1}.radius/body{2}.radius)]);
bodies = length(body);
fps = 20;
g = 9.81; % gravity
rho = 7850; % [kg/m^3]
numCoords = bodies * 3;
numConstr = numCoords;
%------------------------------

for k=1:bodies
     body{k}.mass = (body{k}.radius^2 * pi) * depth * rho; % kg
end
m = massmatrix;


% ============= Solve kinematic equations =============
qBadguess = zeros(numConstr, 1);
OPTIMSEToptions_default = optimset('fsolve'); % get default values -
maybe use ('Display','off')
     OPTIMSEToptions = optimset(OPTIMSEToptions_default, ...
         'TolFun',1e-15, 'TolX',1e-15, 'Display','off');
ODESEToptions=odeset(OPTIMSEToptions_default,'RelTol',1e-5);

[qInit, fval, exitflag, output] =...
     fsolve(@(q) phi_constraints(q), qBadguess, OPTIMSEToptions);
% ============= Solve kinematic equations =============
end


function m = massmatrix
globals
m = zeros(numConstr, numCoords);
for k=1:bodies
     in = k*3-2:k*3-1;
     m(in,in) = diag( repmat(body{k}.mass, 1, 2) ); % body mass [kg]
     m(k*3,k*3) = body{k}.mass * body{k}.radius^2 / 2; % Izz
end
end % function m = massmatrix( body )


function residual = phi_constraints(q,varargin)
globals

r1 = body{1}.radius;
r2 = body{2}.radius;
keyboard
ta = tan(alpha); % <====== HERE THERE IS AN ERROR, BUT WHY ???????

residual = [...
     q(1); % x1 = 0
     q(2); % y1 = 0
     q(3); % theta1 = 0
     q(4)-( r1 + r2 ); % x2 = somewhere...
     q(5); % y2 = 0
     q(1)*ta + q(2) + r1*q(3) - q(4)*ta - q(5) + r2*q(6)]; % gear constraint
end
=========================================

If I stand where it says keyboard and select ta = tan(alpha) and press
F9, then I get that ta = 0.3640.... But if I press F10 I get this:

----------------------------
??? Error using ==> alpha
Too many output arguments.

Error in ==> test>phi_constraints at 69
ta = tan(alpha);

Error in ==> test>@(q)phi_constraints(q) at 44
     fsolve(@(q) phi_constraints(q), qBadguess, OPTIMSEToptions);

Error in ==> fsolve at 248
             fuser = feval(funfcn{3},x,varargin{:});

Error in ==> test at 43
[qInit, fval, exitflag, output] =...

Caused by:
     Failure in initial user-supplied objective function evaluation.
FSOLVE cannot continue.
----------------------------


That is the weirdest thing I've EVER tried.................. Is my
matlab version corrupt or something?

I press F9: It works...

I press F10: It doesn't work...

What the h*ll ? I don't understand this... Tangent always return 1
scalar if you give it a scalar as input, right? What's so special about
tan(20 degress) in this function? What is it I don't see?

aaaaah, after having spent around 1-1,5 hours I suddenly found out that
not only is alpha a variable in my program - it is ALSO a function.... DOH !

It should be disallowed to make variable names the same as function
names and you should (preferably) warn about it as soon as declared,
Mathworks...

------------------------


  ALPHA - Get or set alpha properties for objects in the current Axis

   ALPHA(VALUE) - On all children of GCA, set an alpha property to VALUE.
   ALPHA(OBJECT, VALUE) - Set the alpha on OBJECT to VALUE

   Use a single alpha value for the object

   ALPHA(scalar) - Set the face alpha to be the value of scalar
   ALPHA('flat') - Set the face alpha to be flat.
   ALPHA('interp') - Set the face alpha to be interp. (if applicable.)
   ALPHA('texture')- Set the face alpha to be texture. (if applicable.)
   ALPHA('opaque') - Set the face alpha to be 1.
   ALPHA('clear') - Set the face alpha to be 0.

   Specify an alpha value for each element in the object's data.

   ALPHA(MATRIX) - Set the alphadata to be MATRIX.
   ALPHA('x') - Set the alphadata to be the same as the x data.
   ALPHA('y') - Set the alphadata to be the same as the y data.
   ALPHA('z') - Set the alphadata to be the same as the z data.
   ALPHA('color') - Set the alphadata to be the same as the color data.
   ALPHA('rand') - Set the alphadata to be random values.

   ALPHA('scaled') - Set the alphadatamapping to scaled.
   ALPHA('direct') - Set the alphadatamapping to direct.
   ALPHA('none') - Set the alphadatamapping to none.

   See also alim, alphamap

     Reference page in Help browser
        doc alpha

http://www.youtube.com/watch?v=g6GuEswXOXo

"someone" <newsboost@gmail.com> wrote in message
news:jtk7ns$alh$1@dont-email.me...
>
>
> aaaaah, after having spent around 1-1,5 hours I suddenly found out that
> not only is alpha a variable in my program - it is ALSO a function.... DOH
> !

Yes, and you're "poofing" it into your program. That's a Bad Thing. [Search
the newsgroup for that term for an explanation.]

The solution is to AVOID using global variables and to avoid this "poofing".
Instead see the Note in the Description section of the documentation page
for FSOLVE.

http://www.mathworks.com/help/toolbox/optim/ug/fsolve.html

That discusses the preferred ways to pass additional parameters into the
function you specify as the first input argument to FSOLVE.

> It should be disallowed to make variable names the same as function names
> and you should (preferably) warn about it as soon as declared,
> Mathworks...

Then code like this would error (which is what I assume you mean when you
say "disallowed"):

for i = 1:10
    % do something with i
end

Yes, i is a function in MATLAB.

http://www.mathworks.com/help/techdoc/ref/i.html

It's also commonly used as a loop variable. Changing that would be a rather
LARGE backwards incompatibility and would break LOTS of people's code.

*snip help text for ALPHA*

--
Steve Lord
slord@mathworks.com
To contact Technical Support use the Contact Us link on
http://www.mathworks.com

On 07/11/2012 06:57 PM, Steven_Lord wrote:
>
>
> "someone" <newsboost@gmail.com> wrote in message
> news:jtk7ns$alh$1@dont-email.me...
>>
>>
>> aaaaah, after having spent around 1-1,5 hours I suddenly found out
>> that not only is alpha a variable in my program - it is ALSO a
>> function.... DOH !
>
> Yes, and you're "poofing" it into your program. That's a Bad Thing.
> [Search the newsgroup for that term for an explanation.]

I've searched for it. I don't think I'm "poofing" it because it was a
global variable and what I read what people who used eval and load could
"poof". Anyway, now I learnt not to "poof" with load or eval unless I
cannot avoid it.

> The solution is to AVOID using global variables and to avoid this
> "poofing". Instead see the Note in the Description section of the
> documentation page for FSOLVE.
>
> http://www.mathworks.com/help/toolbox/optim/ug/fsolve.html
>
> That discusses the preferred ways to pass additional parameters into the
> function you specify as the first input argument to FSOLVE.

I see, yes, thank you very much.
Very inspiring to read - I'm however not sure if I'll completely avoid
my global variables because I have a bigger program where some of the
values are things I use in almost ALL my functions, hence using global
variables is an easy (=quick) solution. You're right, that if I had more
time and did something more professionally then I should probably avoid
global variables - I agree.

>> It should be disallowed to make variable names the same as function
>> names and you should (preferably) warn about it as soon as declared,
>> Mathworks...
>
> Then code like this would error (which is what I assume you mean when
> you say "disallowed"):
>
> for i = 1:10
> % do something with i
> end
>
> Yes, i is a function in MATLAB.

That (however) I knew! And exactly for that reason I never use i and j
in my loops, I use "k" and "z" mostly...

> http://www.mathworks.com/help/techdoc/ref/i.html
>
> It's also commonly used as a loop variable. Changing that would be a
> rather LARGE backwards incompatibility and would break LOTS of people's
> code.

I see your point, but I have a suggestion then:

> *snip help text for ALPHA*

How about if you change "dbstop" and add a new option in the next matlab
release so people can do:

dbstop ON stupidVariableNames

Then they can turn this on and off as they like? Anyway, I usually try
to write "help (variable_name)" when I get strange errors and when I'm
in doubt about using a name - in this case however, I forgot to check
this because alpha is such a common variable name (at least I thought it
was)...

Anyway, thank you Sir Mathworks!

"someone" <newsboost@gmail.com> wrote in message
news:jtmg73$f2f$1@dont-email.me...
> On 07/11/2012 06:57 PM, Steven_Lord wrote:
>>
>>
>> "someone" <newsboost@gmail.com> wrote in message
>> news:jtk7ns$alh$1@dont-email.me...
>>>
>>>
>>> aaaaah, after having spent around 1-1,5 hours I suddenly found out
>>> that not only is alpha a variable in my program - it is ALSO a
>>> function.... DOH !
>>
>> Yes, and you're "poofing" it into your program. That's a Bad Thing.
>> [Search the newsgroup for that term for an explanation.]
>
> I've searched for it. I don't think I'm "poofing" it because it was a
> global variable and what I read what people who used eval and load could
> "poof". Anyway, now I learnt not to "poof" with load or eval unless I
> cannot avoid it.

There's no indication to MATLAB when it's parsing the function that the
identifier alpha refers to a variable (it doesn't "look into" the script at
that point) but you're expecting it to use the variable named alpha at
run-time. That's "poofing." LOAD and EVAL are the two most common ways to do
it, but creating the variable in a script and using it (and never assigning
to it) in your function will also do it.

>> The solution is to AVOID using global variables and to avoid this
>> "poofing". Instead see the Note in the Description section of the
>> documentation page for FSOLVE.
>>
>> http://www.mathworks.com/help/toolbox/optim/ug/fsolve.html
>>
>> That discusses the preferred ways to pass additional parameters into the
>> function you specify as the first input argument to FSOLVE.
>
> I see, yes, thank you very much.
> Very inspiring to read - I'm however not sure if I'll completely avoid my
> global variables because I have a bigger program where some of the values
> are things I use in almost ALL my functions, hence using global variables
> is an easy (=quick) solution. You're right, that if I had more time and
> did something more professionally then I should probably avoid global
> variables - I agree.
>
>>> It should be disallowed to make variable names the same as function
>>> names and you should (preferably) warn about it as soon as declared,
>>> Mathworks...
>>
>> Then code like this would error (which is what I assume you mean when
>> you say "disallowed"):
>>
>> for i = 1:10
>> % do something with i
>> end
>>
>> Yes, i is a function in MATLAB.
>
> That (however) I knew! And exactly for that reason I never use i and j in
> my loops, I use "k" and "z" mostly...

Good, but there are a lot of other people that don't know that or use them
as variables anyway.

>> It's also commonly used as a loop variable. Changing that would be a
>> rather LARGE backwards incompatibility and would break LOTS of people's
>> code.
>
> I see your point, but I have a suggestion then:
>
>> *snip help text for ALPHA*
>
> How about if you change "dbstop" and add a new option in the next matlab
> release so people can do:
>
> dbstop ON stupidVariableNames

I'm not entirely sure what you're asking for here; if you feel strongly
about this, please submit it as an enhancement request to Technical Support
and they will make sure it gets into the appropriate development team's
section of the enhancement database.

> Then they can turn this on and off as they like? Anyway, I usually try to
> write "help (variable_name)" when I get strange errors and when I'm in
> doubt about using a name - in this case however, I forgot to check this
> because alpha is such a common variable name (at least I thought it
> was)...

While we're discussing Greek letters, you'll probably also want to avoid
variables named BETA and GAMMA.

http://www.mathworks.com/help/techdoc/ref/beta.html

http://www.mathworks.com/help/techdoc/ref/gamma.html

--
Steve Lord
slord@mathworks.com
To contact Technical Support use the Contact Us link on
http://www.mathworks.com

On 07/12/2012 03:41 PM, Steven_Lord wrote:

>> I've searched for it. I don't think I'm "poofing" it because it was a
>> global variable and what I read what people who used eval and load
>> could "poof". Anyway, now I learnt not to "poof" with load or eval
>> unless I cannot avoid it.
>
> There's no indication to MATLAB when it's parsing the function that the
> identifier alpha refers to a variable (it doesn't "look into" the script

hmmm... There IS in fact an indication to Matlab: It's a global variable
defined just above (ok, not explicit in this file but it must've read
the globals.m file just before finding/executing "alpha")...

So it has just read the "globals.m"-file and then it should know that
alpha is a global variable... But apparently Matlab is not that clever,
I see...

 From your explanation and my own understanding, I get that Matlab does
not see anything else than the current file and it doesn't "remember"
anything at all from other files, even global variables when they're
used the way I do it (I define my global variables in a single file so I
don't have to change maybe 10 different input files all the time - then
I include this single file and I know that ALL sub-files/functions see
the same global variables, because they're only defined in 1 file - this
is very nice/quick for me)...

This "poofing" is quite different from other programming languages, I
think. Apparently it is looking at a single file at a time instead of
going in and out of files in the order they're executed...

> at that point) but you're expecting it to use the variable named alpha

I take it that Matlab is just not clever enough to check the list of
global-variables it knows before checking if "alpha" is a function... I
think I understand this concept of "poofing" now... This "poofing" is
probably also not recommended or even allowed in other languages, I think...

> at run-time. That's "poofing." LOAD and EVAL are the two most common
> ways to do it, but creating the variable in a script and using it (and
> never assigning to it) in your function will also do it.

Ok, I get it...
Dumb matlab, sorry :-)

Poofing is really bad, I understand that now...

............
...........

>>> *snip help text for ALPHA*
>>
>> How about if you change "dbstop" and add a new option in the next
>> matlab release so people can do:
>>
>> dbstop ON stupidVariableNames
>
> I'm not entirely sure what you're asking for here; if you feel strongly
> about this, please submit it as an enhancement request to Technical
> Support and they will make sure it gets into the appropriate development
> team's section of the enhancement database.

I have so bad experience with company development support tickets and
opensource tickets that I think I'll just live with this - bad -
behaviour - am too busy to do more now, I should just be careful and
write "help varname" if in doubt in the future...

>> Then they can turn this on and off as they like? Anyway, I usually try
>> to write "help (variable_name)" when I get strange errors and when I'm
>> in doubt about using a name - in this case however, I forgot to check
>> this because alpha is such a common variable name (at least I thought
>> it was)...
>
> While we're discussing Greek letters, you'll probably also want to avoid
> variables named BETA and GAMMA.
>
> http://www.mathworks.com/help/techdoc/ref/beta.html
>
> http://www.mathworks.com/help/techdoc/ref/gamma.html

Yep, thanks you... I usually do this (especially after I realized that
it wasn't so good to use i and j in loops) - in this case I must've
really assumed that Matlab just first checked if it knew the variable
and then afterwards checks if it's a function...

Ok, anyway - thank you very much for your time, Mr. Lord. I'll continue
programming (I'll still check for replies in this thread until nothing
happens for a few days and then I'll be a "offline" from the group until
my next problem, because I'm a bit busy with my programming and report
writing and so on)...

Thanks!

"someone" <newsboost@gmail.com> wrote in message
news:jtnkpb$iu9$1@dont-email.me...
> On 07/12/2012 03:41 PM, Steven_Lord wrote:
>
>>> I've searched for it. I don't think I'm "poofing" it because it was a
>>> global variable and what I read what people who used eval and load
>>> could "poof". Anyway, now I learnt not to "poof" with load or eval
>>> unless I cannot avoid it.
>>
>> There's no indication to MATLAB when it's parsing the function that the
>> identifier alpha refers to a variable (it doesn't "look into" the script
>
> hmmm... There IS in fact an indication to Matlab: It's a global variable
> defined just above (ok, not explicit in this file but it must've read the
> globals.m file just before finding/executing "alpha")...

At _run_ time, yes, MATLAB reads the globals.m file as part of executing
your code.

At _parse_ time, no, MATLAB parses your function as a standalone entity.

MATLAB decides to what the identifier 'alpha' refers at PARSE time, not RUN
time. Could MATLAB "check the definition of alpha" at runtime and use the
variable instead of the function? Sure. But that would mean it would need to
reparse the function after every single script/function call, as any of
those could manipulate the state of the workspace of the function from which
they were called [see GLOBAL, EVALIN, ASSIGNIN, etc.] or change what a
particular function means (by FPRINTFing out a file named alpha.m, for
instance) or do other nasty tricks. That would be slow.

--
Steve Lord
slord@mathworks.com
To contact Technical Support use the Contact Us link on
http://www.mathworks.com

On 07/13/2012 03:28 PM, Steven_Lord wrote:
>
>> hmmm... There IS in fact an indication to Matlab: It's a global
>> variable defined just above (ok, not explicit in this file but it
>> must've read the globals.m file just before finding/executing "alpha")...
>
> At _run_ time, yes, MATLAB reads the globals.m file as part of executing
> your code.
>
> At _parse_ time, no, MATLAB parses your function as a standalone entity.
>
> MATLAB decides to what the identifier 'alpha' refers at PARSE time, not
> RUN time. Could MATLAB "check the definition of alpha" at runtime and
> use the variable instead of the function? Sure. But that would mean it
> would need to reparse the function after every single script/function
> call, as any of those could manipulate the state of the workspace of the
> function from which they were called [see GLOBAL, EVALIN, ASSIGNIN,
> etc.] or change what a particular function means (by FPRINTFing out a
> file named alpha.m, for instance) or do other nasty tricks. That would
> be slow.

Hmmm... Ok: It must be because it's an interpreted language and not a
compiled language like C, C++ etc (then when you compile you can check
ALL that you want and it'll not affect run speed)... I think this is
"interpreted" so there's no time to do all these checks that for
instance a C/C++ compiler does... I would guess...

If I were good at java, I guess this type of error could also happen
then because there's not time to "re-parse" the whole time...

Ok, thank you - a shame, but that's how it is...