"Steven_Lord" <email@example.com> wrote in message <firstname.lastname@example.org>... > > > "Richard Crozier" <email@example.com> wrote in message > news:firstname.lastname@example.org... > > "Steven_Lord" <email@example.com> wrote in message > > <firstname.lastname@example.org>... > > > >> > >> It's not justification. It's identifying a use case for INTERP1 (and by > >> extension INTERP2, INTERP3, etc.) that we may not have known about, or > >> identifying a use case we did know about as being a more frequent usage > >> of the functionality than we estimated or measured. > >> > > > > Ok, but isn't this something you do for new functions, not ones that have > > been in use for years? > > Identifying use cases we didn't know about? Yes, that's more focused on new > functions. > Recalibrating how "popular" a particular use case is? That applies to both > new functions and older ones. > > > Isn't there research on the use cases from when you first introduced this > > function? What has changed in the intervening years? Have people recently > > stopped wanting to interpolate several sets of data at the same points at > > once? > > > > This reminds me of the ode solvers which have a handy syntax where you can > > supply extra arguments which are also then passed to your solution > > function and event and output functions, but it is deprecated and not > > documented because TMW have decided users are too stupid to understand the > > feature. > > No, that was deprecated because we came up with other ways (anonymous > functions, nested functions) to pass additional inputs to solution, event, > and output functions that: > > 1) Did not prevent us from _ever_ adding additional input arguments to the > ODE solvers by forcing the ODE solvers to treat ALL input arguments after > the 4th (in the case of ODE45) as additional inputs to the user-specified > functions. > 2) Did not require users to have to specify as empty matrices inputs between > the last one they wanted to specify and the additional inputs (a common > source of errors in the Optimization "function functions" like FMINCON; > admittedly not so big a deal in the ODE solvers.) > 3) Was consistent with the new system used by the other "function functions" > like the aforementioned FMINCON. [The main benefit to FMINCON AFAIK was item > 2, as that was a source of a LOT of pain and CSSM postings. Miss one  and > suddenly the first of your additional inputs was treated as your options > structure.] > 4) Did not require ALL the user-specified functions in the ODE* call to > accept ALL the input arguments even if the specific user-specified function > used NONE of them. > > You'll note that the trailing input syntax DOES still work for backwards > compatibility. But we recommend that you use the newer approach for these > four reasons (and possibly others that I can't remember off the top of my > head right now.) > > -- > Steve Lord > email@example.com > To contact Technical Support use the Contact Us link on > http://www.mathworks.com
So item one in your doc from 2003 and your list above translate to "too confusing for users", which I am facetiously taking to be the same as what I said.
Here's one beef I have with anonymous functions:
aninput = rand(1000,1000); infoonaninput = whos('aninput') a = struct('a', @(t,y) y*aninput); whos a = struct('a', @(t,y) y*aninput, 'b', @(t,y) y*aninput, 'c', @(t,y) y*aninput); whos save('test.mat', 'a'); fiinfo = dir('test.mat') fprintf(1, '3 * size of aninput is: %f\n', 3 * infoonaninput.bytes); % now lets see what happens if we get rid of the data clear aninput whos result = a.a(0,0); whos fprintf(1, 'Wow, it still knows about the deleted data, that''s fancy compression!\n');
Now since matlab lies about the size of a, I don't actually know if this data replication happens in RAM too, but in my case I actually have an application where I do something similar to the above, but with many copies of the functions saved and loaded.
Another problem is that the saved function handles don't work across computers because they reference a specific function location.
Nested function, well, nested functions are the work of the devil being merely global variable in disguise, but that's just my opinion.