New behaviour with nested functions hiding builtins
in [Matlab]
|
From: Federico Miorelli on 9 Mar 2010 11:16 Dear all, I installed today R2010a and to my great surprise one script I routinely used started giving incorrect results. Long story short, I traced back the cause to be the presence of a nested function called "times" inside the script. This breaks functionality of the "*" operator without any kind of error or warning, so all multiplications are wrong. In previous Matlab versions this did not happen, meaning that the "times" subroutine was not hiding the operator "*". I wanted to hear your opinion before submitting a bug report, because I believe this is an *extremely* dangerous change of behaviour that completely goes unnoticed! Probably m-lint should give a big warning if a subroutine exists that hides a built-in? Best regards, Federico
From: Matt J on 9 Mar 2010 11:45 "Federico Miorelli" <fmiorelli(a)REMOVEslbTHIS.com> wrote in message <hn5s85$hr4$1(a)fred.mathworks.com>... > Dear all, > > I installed today R2010a and to my great surprise one script I routinely used started giving incorrect results. > Long story short, I traced back the cause to be the presence of a nested function called "times" inside the script. > > This breaks functionality of the "*" operator without any kind of error or warning, so all multiplications are wrong. > In previous Matlab versions this did not happen, meaning that the "times" subroutine was not hiding the operator "*". > > I wanted to hear your opinion before submitting a bug report, because I believe this is an *extremely* dangerous change of behaviour that completely goes unnoticed! > Probably m-lint should give a big warning if a subroutine exists that hides a built-in? ================= I'll reserve judgement until I see more of your code, but it sounds like a pretty serious bug to me. I'd be curious to know what happens if you do a multiplication A*B where A and B are some user-defined class instead of doubles. There's no reason why a nested function, or even a non-nested function, would shadow a times() method at minimum unless that function has been placed in a directory called @double or @myClass or whatever. When MATLAB sees an operation A*B, it's supposed to decides which times() method to apply based on class(A), class(B), and certain dispatching rules, and not simply to take the first times() method it finds in the search path. It looks like, here, MATLAB is skipping those dispatching rules altogether.
From: Federico Miorelli on 9 Mar 2010 11:53 This appears to happen only in debug mode. To reproduce, set a breakpoint at the beginning of the function below and continue when hit. With the breakpoint it will always give 1234 as result, without it will give the correct answer. This does not happen in Matlab 2009b and older. ---------------------------- %%%%%%%%%%%%% function y = multiplyByTen(x) myStruct.value = x; % put value inside a struct (see below) y = 10 * myStruct.value; % use the built-in "*" %%%%%%%%%%%%% % Define a sub-function called like a built-in function [out1,out2] = times(File,varargin) % Make so that function will always return 1234 if called if ~strcmp(date, 'FAIL') out1 = 1234; return; end % Let the parser think that this function works with a struct out1 = File.x; out2 = [];
From: Matt J on 9 Mar 2010 12:13 "Federico Miorelli" <fmiorelli(a)REMOVEslbTHIS.com> wrote in message <hn5udg$ce5$1(a)fred.mathworks.com>... > This appears to happen only in debug mode. > To reproduce, set a breakpoint at the beginning of the function below and continue when hit. > With the breakpoint it will always give 1234 as result, without it will give the correct answer. > This does not happen in Matlab 2009b and older. > ================== I don't have R2010, so I can't reproduce it, but based on the example, it seems abundantly reportable as a bug.
From: Bobby Cheng on 9 Mar 2010 15:32
Can I ask for more info here? Comment/question below. (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? (2) The discrepancy in and out of debug mode should be a bug. Here is are more detail. First, there are two functions, "mtimes" and "times". which can be written as "*" and ".*" respectively. "times" is elementwise multiplication, while "mtimes" is matrix multiply but if one of the input is a scalar, it is essentially doing "times". For example, 10 .* [1 2 3] is the same as 10*[1 2 3] The question here is that whether "mtimes" should react to overloaded "times" in this case. I can see argument from both sides. But for backward compatibility, it is easy to argue that ignoring overloaded "times" is the right thing to do. Regards, ---Bob. "Matt J " <mattjacREMOVE(a)THISieee.spam> wrote in message news:hn5vj0$qm$1(a)fred.mathworks.com... > "Federico Miorelli" <fmiorelli(a)REMOVEslbTHIS.com> wrote in message > <hn5udg$ce5$1(a)fred.mathworks.com>... >> This appears to happen only in debug mode. >> To reproduce, set a breakpoint at the beginning of the function below and >> continue when hit. >> With the breakpoint it will always give 1234 as result, without it will >> give the correct answer. >> This does not happen in Matlab 2009b and older. >> > ================== > > I don't have R2010, so I can't reproduce it, but based on the example, it > seems abundantly reportable as a bug. > |