Prev: Resize Axes in figure....
Next: Very slow serial port objects
From: Matt J on 9 Mar 2010 16:18

I guess it's not a bug. Here's an excerpt from the MATLAB documentation on function precedence (R2009b) which describes this as intended behavior. If previous behavior wasn't consistent with this, I guess it was a bug....


Function Precedence Order

The function precedence order determines the precedence of one function over another based on the type of function and its location on the MATLAB path. MATLAB selects the correct function for a given context by applying the following function precedence rules in the order given here.

For items 3 through 7 in this list, the file MATLAB searches for can be any of four types: an M- or built-in file, preparsed M-file (P-Code), compiled C or Fortran file (MEX-file), or Simulink® model (MDL-file). See Multiple Implementation Types for more on this.

1.

Variable

Before assuming that a name should match a function, MATLAB checks the current workspace to see if it matches a variable name. If MATLAB finds a match, it stops the search.
2.

Subfunction

Subfunctions take precedence over all other M-file functions and overloaded methods that are on the path and have the same name. Even if the function is called with an argument of type matching that of an overloaded method, MATLAB uses the subfunction and ignores the overloaded method.
From: Bobby Cheng on 9 Mar 2010 21:38
Matt,

While this is all true, consider this example, I use the function name
instead of .* to remove any confusion.

function y = test(x)
y = mtimes(10,x);
%subfunction
function z = times(a,b)
z = a+b;

While times is overloaded in the local scope of test.m, the function mtimes
does not react to the overloaded times in R2009b or before. It make sense
because the example does not overloaded mtimes. In R2010a in debug mode, the
overloaded times is called and this is where the behaviour has changed. For
backward compatibility, it should consider a bug.

More importantly, I think the best way going forward is not to use a
function name that is the same as a built-in function, particularly one that
with an operator. Why? Consider the following, say this does what you want

function y = test(x)
y = 10*x;
%subfunction
function z = times(a,b)
z = a+b;

Let generalize it in the following three ways and you would have broken your
code

function y = test(x)
y = 10.*x;
%subfunction
function z = times(a,b)
z = a+b;

or

function y = test(x,w)
y = w.*x;
%subfunction
function z = times(a,b)
z = a+b;

or

function y = test(x,w)
y = bsxfun(@times, w, x);
%subfunction
function z = times(a,b)
z = a+b;

You can read the doc all day long. But it is so easy to make a mistake. It
is a genuine trap. So be careful.

---Bob.

"Matt J " <mattjacREMOVE(a)THISieee.spam> wrote in message
news:hn6dua$5hl$1(a)fred.mathworks.com...
>
> I guess it's not a bug. Here's an excerpt from the MATLAB documentation on
> function precedence (R2009b) which describes this as intended behavior. If
> previous behavior wasn't consistent with this, I guess it was a bug....
>
>
> Function Precedence Order
>
> The function precedence order determines the precedence of one function
> over another based on the type of function and its location on the MATLAB
> path. MATLAB selects the correct function for a given context by applying
> the following function precedence rules in the order given here.
>
> For items 3 through 7 in this list, the file MATLAB searches for can be
> any of four types: an M- or built-in file, preparsed M-file (P-Code),
> compiled C or Fortran file (MEX-file), or Simulink� model (MDL-file). See
> Multiple Implementation Types for more on this.
>
> 1.
>
> Variable
>
> Before assuming that a name should match a function, MATLAB checks
> the current workspace to see if it matches a variable name. If MATLAB
> finds a match, it stops the search.
> 2.
>
> Subfunction
>
> Subfunctions take precedence over all other M-file functions and
> overloaded methods that are on the path and have the same name. Even if
> the function is called with an argument of type matching that of an
> overloaded method, MATLAB uses the subfunction and ignores the overloaded
> method.
>


From: Federico Miorelli on 10 Mar 2010 03:05
"Bobby Cheng" <bcheng(a)mathworks.com> wrote:
> (1) You mention that the script does not work when you upgrade to R2010a. I
> don't know if you are runnning debug mode then. If not, I wonder what else
> is broken. Does you code work correctly in normal mode?

My code works OK in normal mode, the error happens only in debug mode.
This is where I would say it is a bug, or at least a VERY dangerous behaviour.

> In R2010a in debug mode, the overloaded times is called and this is where
> the behaviour has changed. For backward compatibility, it should consider a bug.
> More importantly, I think the best way going forward is not to use a
> function name that is the same as a built-in function, particularly one that
> with an operator.
> ...
> You can read the doc all day long. But it is so easy to make a mistake. It
> is a genuine trap. So be careful.

Couldn't agree more with everything you wrote.

Best regards,
Federico
From: Jan Simon on 10 Mar 2010 04:22
Dear Federico!

> I installed today R2010a and to my great surprise one script I routinely used started giving incorrect results.

Just for clarification: Did the problem appear at first because you've started your script in debug mode?

Kind regards, Jan
From: Federico Miorelli on 10 Mar 2010 05:09
"Jan Simon" <matlab.THIS_YEAR(a)nMINUSsimon.de> wrote in message
> Just for clarification: Did the problem appear at first because you've started your script in debug mode?

Hi Jan,
yes it did! It's just when I tried to write a little script to reproduce the bug that I noticed that it didn't happen in normal mode.
Understanding this drove me almost crazy by the way :)
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Resize Axes in figure....
Next: Very slow serial port objects