MATLAB and Simulink resources for Arduino, LEGO, and Raspberry Pi

# Thread Subject: Why is interp1(x,Y,...) being removed?

 Subject: Why is interp1(x,Y,...) being removed? From: Richard Crozier Date: 10 Oct, 2012 10:08:07 Message: 1 of 54 Why is the syntax interp1(x,Y,...) where x is a vector and Y is an array representing multiple value sets being removed in a future release? as an example it is sugested that x = (1:5)'; V = [x, 2*x, 3*x]; xq = (1:0.5:5)'; Vq = interp1(x, V, xq); be replaced with x = (1:5)'; V = [x, 2*x, 3*x]; xq = (1:0.5:5)'; F = griddedInterpolant(x, V(:,1)); for n=1:3   F.Values = V(:, n);   Vq(:, n) = F(xq); end This seems like a retrograde step to me, and whatever happens, I will not be going through all my old code and changing it to the new syntax. I don't see why the original should actually be removed. If it is removed, I will not upgrade my version of Matlab (although the new GUI has already brought that decision pretty close anyway). Why can't you make interp1 quetly use griddedInterpolent under the hood if you're so desperate to change it? It's annoying that I now feel I need to carefully inspect all the changes between releases before considering upgrading, and wondering if there will come a time when I can no longer upgrade and must seriously consider porting my code to another system.
 Subject: Why is interp1(x,Y,...) being removed? From: Matt J Date: 10 Oct, 2012 15:09:09 Message: 2 of 54 "Richard Crozier" wrote in message ... > > This seems like a retrograde step to me, and whatever happens, I will not be going through all my old code and changing it to the new syntax. I don't see why the original should actually be removed. If it is removed, I will not upgrade my version of Matlab (although the new GUI has already brought that decision pretty close anyway). > > Why can't you make interp1 quetly use griddedInterpolent under the hood if you're so desperate to change it? It's annoying that I now feel I need to carefully inspect all the changes between releases before considering upgrading, and wondering if there will come a time when I can no longer upgrade and must seriously consider porting my code to another system. ============== I don't understand the beef everyone has with the GUI, but I am bothered by all these retroactive changes in the behavior of commands. Worse I think than certain features being removed altogether is that the behavior of some commands will silently change, e.g., unique, setdiff, etc... That will make detecting malfunctions they cause potentially difficult. I think it would be much better to just invent a command with a new name, e.g. NOREPEATS instead of UNIQUE. Sure that could create a lot of work for the folks at TMW, changing all their stock mcode to use the new version of the command, but I think that that's the most appropriate place to put the burden.
 Subject: Why is interp1(x,Y,...) being removed? From: Richard Crozier Date: 10 Oct, 2012 16:50:08 Message: 3 of 54 "Matt J" wrote in message ... > I don't understand the beef everyone has with the GUI, but I am bothered by all these retroactive changes in the behavior of commands. Worse I think than certain features being removed altogether is that the behavior of some commands will silently change, e.g., unique, setdiff, etc... That will make detecting malfunctions they cause potentially difficult. > > I think it would be much better to just invent a command with a new name, e.g. NOREPEATS instead of UNIQUE. Sure that could create a lot of work for the folks at TMW, changing all their stock mcode to use the new version of the command, but I think that that's the most appropriate place to put the burden. Well the GUI has been changing in bad ways for a while, while improving in others. I remember a time when you could start a long running Matlab computation, go to the editor, and then miraculously open a file for editing at the same time, you know, so you can code while you wait for the computation to run. This feature was present in r2008b. Now I must open a whole new Matlab instance to do the same thing in r2012a, using up about 200MB of RAM. There was also a time when the editor could be opened completely separately from Matlab which was also useful occasionally. Maybe TMW are trying to tell me I should be learning emacs or something.
 Subject: Why is interp1(x,Y,...) being removed? From: dpb Date: 10 Oct, 2012 18:21:17 Message: 4 of 54 On 10/10/2012 5:08 AM, Richard Crozier wrote: > Why is the syntax interp1(x,Y,...) where x is a vector and Y is an array > representing multiple value sets being removed in a future release? > ...[code example elided for brevity]... > This seems like a retrograde step to me, and whatever happens, I will > not be going through all my old code and changing it to the new syntax. > I don't see why the original should actually be removed. ... > > Why can't you make interp1 quetly use griddedInterpolent under the hood > if you're so desperate to change it?... Fully agree on these non-necessary functional changes that break compatibility and remove functionality. As an admitted guess, it seems TMW is hellbent on the OOP direction w/ methods instead of an "old-fashioned" function call despite possible performance penalties and definite compatibility issues. This is, imo, _a_bad_thing_ (tm) and the more stink raised the better for the user. It seems despite protestations to the contrary TMW really doesn't "get it" on compatibility and consistency being a virtue. _IF_ (the proverbial "big if"), as MattJ suggests TMW thinks it is absolutely imperative to implement a new functionality the route is another function (despite the already almost overwhelming namespace pollution problem) rather than breaking existing code. _ONLY_ if there is an absolutely compelling reason that a change is absolutely mandatory in order to provide new and enhanced performance should it be considered ok to cause a change in previous program behavior and even then best practice would be to be able to support both. I revert again to languages w/ actual formal Standard documents and particularly Fortran wherein it has been a key element in its evolution to _not_ break legacy code--TMW should pay far more attention than the apparent lip service continuity actually seems to get. --
 Subject: Why is interp1(x,Y,...) being removed? From: Bruno Luong Date: 10 Oct, 2012 20:17:08 Message: 5 of 54 TMW, you start to make too many wrong turns. Bruno
 Subject: Why is interp1(x,Y,...) being removed? From: james bejon Date: 10 Oct, 2012 20:56:08 Message: 6 of 54 I had no idea "unique" was changing in this way. This means I'm going to have to alter quite a lot of code--which, now that it's written, tested, running, etc., is a real nuisance. On the whole, I love Matlab; but I see this as a pretty poor idea. I'm all for new features; but I don't see the value of making future releases handle existing syntax differently to old versions. At the very least, you'd think that TMW could create a function which sets a persistent variable that makes sure everything runs as per a certain release. Then, at the top of a file, I could call, say, runAsPerVersion('2010a') and I'd be done...
 Subject: Why is interp1(x,Y,...) being removed? From: Richard Crozier Date: 10 Oct, 2012 21:14:08 Message: 7 of 54 "james bejon" wrote in message ... > I had no idea "unique" was changing in this way. This means I'm going to have to alter quite a lot of code--which, now that it's written, tested, running, etc., is a real nuisance. On the whole, I love Matlab; but I see this as a pretty poor idea. I'm all for new features; but I don't see the value of making future releases handle existing syntax differently to old versions. > > At the very least, you'd think that TMW could create a function which sets a persistent variable that makes sure everything runs as per a certain release. Then, at the top of a file, I could call, say, runAsPerVersion('2010a') and I'd be done... As TMW break backwards compatibility, at some point the gradient of work they create to maintain my Matlab code becomes greater than the gradient of work to convert to competing systems.
 Subject: Why is interp1(x,Y,...) being removed? From: TideMan Date: 10 Oct, 2012 21:47:03 Message: 8 of 54 On Thursday, October 11, 2012 10:14:08 AM UTC+13, Richard Crozier wrote: > "james bejon" wrote in message ... > > As TMW break backwards compatibility, at some point the gradient of work they create to maintain my Matlab code becomes greater than the gradient of work to convert to competing systems. Well, that happened to me back in 2006 when TMW changed from 2006a to 2006b. There were so many differences, that many of my programs no longer worked. I've been using 2006a since, with no ill effects. Indeed, I don't know of anything I've missed from the subsequent updates that I haven't been able to get from the FedEx or develop myself.
 Subject: Why is interp1(x,Y,...) being removed? From: dpb Date: 11 Oct, 2012 14:02:52 Message: 9 of 54 On 10/10/2012 10:09 AM, Matt J wrote: ... > name, e.g. NOREPEATS instead of UNIQUE. Sure that could create a lot of > work for the folks at TMW, changing all their stock mcode to use the new > version of the command, but I think that that's the most appropriate > place to put the burden. Now there's a thought! :) What TMW should use as a litmus test...think deeply about the fact that they're putting such a burden on every client's code maintenance staff and/or every researcher/engineer w/ a stable code base. Perhaps clients should start billing TMW for their outlays in making fixes for such gratuitous changes... --
 Subject: Why is interp1(x,Y,...) being removed? From: dpb Date: 11 Oct, 2012 14:10:49 Message: 10 of 54 On 10/10/2012 5:08 AM, Richard Crozier wrote: > Why is the syntax interp1(x,Y,...) where x is a vector and Y is an array > representing multiple value sets being removed in a future release? ... > This seems like a retrograde step to me, and whatever happens, I will > not be going through all my old code and changing it to the new syntax. ... Indeed, altho have an old version here and doubt if will ever upgrade having retired, if it were to happen to me I'd likely alias the new function to behave as the old in one way or another--either replace the new or rename it or add a wrapper or... Whatever, I would likely change the behavior of Matlab to keep consistency rather than allow such a change to break working code. Where one runs into real trouble is if in an organization where one doesn't have the leeway to do such things--then it's a double-whammy in that they have a controlled environment on a vendor package as well as the application code base and now they've got a real problem. What if it's in a serious application such as medical or nuclear or auto where there are all sorts of regulatory issues as well, potentially???? It's just a dumb idea and emphasizes the problem of relying on a vendor-specific product for critical applications, unfortunately. :( _NOT_ a good idea, here, TMW, but you've been told that before... --
 Subject: Why is interp1(x,Y,...) being removed? From: Matt J Date: 11 Oct, 2012 14:54:08 Message: 11 of 54 dpb wrote in message ... > > > name, e.g. NOREPEATS instead of UNIQUE. Sure that could create a lot of > > work for the folks at TMW, changing all their stock mcode to use the new > > version of the command, but I think that that's the most appropriate > > place to put the burden. > > Now there's a thought! :) > > What TMW should use as a litmus test...think deeply about the fact that > they're putting such a burden on every client's code maintenance staff > and/or every researcher/engineer w/ a stable code base. > > Perhaps clients should start billing TMW for their outlays in making > fixes for such gratuitous changes... =============== The more I think about this, the more it puzzles me. In order to make sure their own Mcode wouldn't break, they had to have a team of developers review every occurrence of 'unique' in the entire code. Once you've committed to that effort, isn't it a trivial additional burden to edit those occurrences to use a different function?
 Subject: Why is interp1(x,Y,...) being removed? From: Richard Crozier Date: 11 Oct, 2012 15:13:08 Message: 12 of 54 > > The more I think about this, the more it puzzles me. In order to make sure their own Mcode wouldn't break, they had to have a team of developers review every occurrence of 'unique' in the entire code. Once you've committed to that effort, isn't it a trivial additional burden to edit those occurrences to use a different function? This applies doubly so for the removal of the interp1(x,Y,...) syntax. They don't need to remove it, but presumeably now have to devote resources to searching out and replacing every occurance of this in their own code and toolboxes. It seems to me as well it is not a simple string replace either. The only reason I can think of to do this is to intentionally introduce backwards incompatibility, as it actually costs them time and resources to do it. Someone has costed these decisions and decided they're a good idea. I can speculate a few reasons why they would want to do this, none of which make me want to stay loyal to TMW.
 Subject: Why is interp1(x,Y,...) being removed? From: dpb Date: 11 Oct, 2012 17:33:27 Message: 13 of 54 On 10/11/2012 9:54 AM, Matt J wrote: > dpb wrote in message ... ... >> Perhaps clients should start billing TMW for their outlays in making >> fixes for such gratuitous changes... ... > > The more I think about this, the more it puzzles me. In order to make > sure their own Mcode wouldn't break, they had to have a team of > developers review every occurrence of 'unique' in the entire code. Once > you've committed to that effort, isn't it a trivial additional burden to > edit those occurrences to use a different function? I'm not sure I'd label it trivial, necessarily, altho it depends on just what the actual syntax difference(s) are as to whether it is something as simple as can be accomplished reliably by a replace tool automagically or not (and I've looked at before but don't recall what the difference/change in unique() is). In the particular calling sequence of interp1() that started this thread, there's additional code required to be added to get the same result--that's always a place to introduce a new error: not necessarily a high probability but any code modification like any surgery has a non-zero risk of negative side consequences. And, of course, once one makes the changes then one has the issue of reverifying through whatever process that requires. All in all, it's hard to see why this particular behavior would be singled out for removal and if TMW thinks it's important to recode the routine for some reason, at a minimum they could/should ensure it doesn't break anything (again w/ the one caveat of there being some fundamental incompatibility that prevents it and there surely isn't that in this case). --
 Subject: Why is interp1(x,Y,...) being removed? From: Matt J Date: 11 Oct, 2012 17:49:08 Message: 14 of 54 dpb wrote in message ... > > > The more I think about this, the more it puzzles me. In order to make > > sure their own Mcode wouldn't break, they had to have a team of > > developers review every occurrence of 'unique' in the entire code. Once > > you've committed to that effort, isn't it a trivial additional burden to > > edit those occurrences to use a different function? > > I'm not sure I'd label it trivial, necessarily, altho it depends on just > what the actual syntax difference(s) are as to whether it is something > as simple as can be accomplished reliably by a replace tool > automagically or not (and I've looked at before but don't recall what > the difference/change in unique() is). No, it doesn't matter whether you can automate the change or not. You have two mutually exclusive scenarios: (1) The change you're making to the function doesn't affect previous toolbox mcode. Solution: Don't change the function at all. Offer the new functionality in a new MATLAB command of a different name. (2) The change you're making DOES affect previous toolbox mcode. Solution: The previous toolbox code has to be edited anyway to accomodate the change. If it has to be edited anyway, replace the call to the old command with a call to a new command of a different name.
 Subject: Why is interp1(x,Y,...) being removed? From: Penny Anderson Date: 12 Oct, 2012 19:23:10 Message: 15 of 54 Hi Richard, Thanks for your feedback. For this particular item, we are extremely interested in hearing from customers who are using this functionality of interp1. Can you please tell us a little bit more about what kinds of problems you are using interp1 to solve in this way? Since announcing in R2012a our intention to remove this syntax in a future release, we have received feedback from a few customers concerned about this change. I'm happy to announce we'll reconsider this decision. Can you please let me know if any of the other proposed changes to interp1 gave you any cause for concern? Thanks, Penny Anderson MathWorks, Inc. "Richard Crozier" wrote in message news:k53he7$onf$1@newscl01ah.mathworks.com... > Why is the syntax interp1(x,Y,...) where x is a vector and Y is an array > representing multiple value sets being removed in a future release? > > as an example it is sugested that > > x = (1:5)'; V = [x, 2*x, 3*x]; > xq = (1:0.5:5)'; > Vq = interp1(x, V, xq); > > be replaced with > x = (1:5)'; V = [x, 2*x, 3*x]; > xq = (1:0.5:5)'; > F = griddedInterpolant(x, V(:,1)); > for n=1:3 > F.Values = V(:, n); > Vq(:, n) = F(xq); > end > > This seems like a retrograde step to me, and whatever happens, I will not > be going through all my old code and changing it to the new syntax. I > don't see why the original should actually be removed. If it is removed, I > will not upgrade my version of Matlab (although the new GUI has already > brought that decision pretty close anyway). > > Why can't you make interp1 quetly use griddedInterpolent under the hood if > you're so desperate to change it? It's annoying that I now feel I need to > carefully inspect all the changes between releases before considering > upgrading, and wondering if there will come a time when I can no longer > upgrade and must seriously consider porting my code to another system.
 Subject: Why is interp1(x,Y,...) being removed? From: Penny Anderson Date: 12 Oct, 2012 19:32:10 Message: 16 of 54 "james bejon" wrote in message news:k54nd8$mcf$1@newscl01ah.mathworks.com... > I had no idea "unique" was changing in this way. This means I'm going to > have to alter quite a lot of code--which, now that it's written, tested, > running, etc., is a real nuisance. On the whole, I love Matlab; but I see > this as a pretty poor idea. I'm all for new features; but I don't see the > value of making future releases handle existing syntax differently to old > versions. > > At the very least, you'd think that TMW could create a function which sets > a persistent variable that makes sure everything runs as per a certain > release. Then, at the top of a file, I could call, say, > runAsPerVersion('2010a') and I'd be done... Hi James, That would quickly become an intractable problem for MathWorks to essentially support k thousand functions * n releases, including all the possible combinations, particularly if allowed on a per file basis as you suggest. The balance between compatibility and progress is well understood, both the pains and benefits, I am afraid. I want to assure you that we weigh each item seriously before phasing in a change. We don't always get it right, and that's why feedback from customers is so valuable. However, I do want to let you and other folks using unique and the other set functions that we did provide a limited way to get what you want. Invoke the 'legacy' flag to have your code continue to work the way it does in R2012a and older releases. This is documented in the release notes and will protect your code if you are concerned about it breaking in an upcoming release. If you want to see the effect of the upcoming changes, try using the 'R2012a' flag in R2012a or subsequent releases. Thanks, Penny Anderson MathWorks, Inc.
 Subject: Why is interp1(x,Y,...) being removed? From: Matt J Date: 12 Oct, 2012 19:49:19 Message: 17 of 54 "Penny Anderson" wrote in message ... > > However, I do want to let you and other folks using unique and the other set > functions that we did provide a limited way to get what you want. Invoke the > 'legacy' flag to have your code continue to work the way it does in R2012a > and older releases. This is documented in the release notes and will protect > your code if you are concerned about it breaking in an upcoming release. If > you want to see the effect of the upcoming changes, try using the 'R2012a' > flag in R2012a or subsequent releases. ============== Penny, what is the rationale behind changing the behavior of old commands? If you've found ways to improve them, releasing the improved version under a different name (as you did with griddedInterpolant vis-a-vis INTERPN) seems to be the most painless change. Is it because you want the improvement to be inherited by toolbox code that uses the old command? If so doesn't that code have to be edited anyway, to make sure the new behavior of the command doesn't break the toolbox? And if you are editing the toolbox code anyway, why not replace calls to the old command with a call to a new command, again of a different name?
 Subject: Why is interp1(x,Y,...) being removed? From: james bejon Date: 12 Oct, 2012 20:50:17 Message: 18 of 54 > Hi James, > > That would quickly become an intractable problem for MathWorks to > essentially support k thousand functions * n releases, including all the > possible combinations, particularly if allowed on a per file basis as you > suggest. Agreed--but then why not just discontinue support for old versions of functions rather than modify their existing behaviour?
 Subject: Why is interp1(x,Y,...) being removed? From: dpb Date: 12 Oct, 2012 21:05:51 Message: 19 of 54 On 10/12/2012 2:32 PM, Penny Anderson wrote: > "james bejon" wrote in message > news:k54nd8$mcf$1@newscl01ah.mathworks.com... ... >> At the very least, you'd think that TMW could create a function which >> sets a persistent variable that makes sure everything runs as per a >> certain release. Then, at the top of a file, I could call, say, >> runAsPerVersion('2010a') and I'd be done... ... > That would quickly become an intractable problem for MathWorks to > essentially support k thousand functions * n releases, including all the > possible combinations, particularly if allowed on a per file basis as > you suggest. The balance between compatibility and progress is well > understood, both the pains and benefits, I am afraid. I want to assure > you that we weigh each item seriously before phasing in a change. We > don't always get it right, and that's why feedback from customers is so > valuable. I will agree to that not being tractable but it wouldn't be an issue if weren't so seemingly hellbent on breaking things that don't need to be broke. Why not do the asking _before_ the releasing? The "balance" as you call it between compatibility and progress appears to be weighted heavily towards TMW's viewpoint as opposed to that of customers. > However, I do want to let you and other folks using unique and the other > set functions that we did provide a limited way to get what you want. ... Far better would be to release the new functions as either consistent in effects w/ the old one (only making internal changes iow) or to introduce them as new functions, not replacing them and destroying previous work of and making more work for your customers. At worst you can deprecate usage and cease to upgrade functions but this idea of either removing them entirely or emasculating them as in the interp1 behavior that began this thread or simply making their behavior different but otherwise indistinguishable from which is possibly the most insidious change since it could cause silent error (S Lord mentioned earlier today about the "wrong answers fast" syndrome; this could be "wrong answers silently") is just a terrible path to embark down. Another example I've used in the past is textread() -- to the best of my knowldege there's no longer a way to do what it can do and return an array instead of a cell w/ a non-deprecated function. That just seems retrogressive and for what purpose? If you don't want to maintain it any longer, fine--just keep it as is but don't remove it from the distribution--at least w/o introducing the unique (so to speak :) ) features it has into something else. I bring yet again to your attention the much more serious consideration of compatibility of the Fortran Standards group in only breaking things that were entirely impossible to maintain or removing features that were almost universally agreed to have been bad decisions. The thing the customer base has to protect them there is a consortium and a worldwide review/balloting process. I'm certainly not saying TMW can open up Matlab that much but certainly it needs imo somebody advocating more strongly for the customer base and stability than is presently occurring. --
 Subject: Why is interp1(x,Y,...) being removed? From: dpb Date: 12 Oct, 2012 21:15:20 Message: 20 of 54 On 10/12/2012 2:23 PM, Penny Anderson wrote: ... > Can you please tell us a little bit more about what kinds of problems > you are using interp1 to solve in this way? Why should customers (present or future) have to justify their usage to TMW? The point of Matlab is to be a general-purpose toolset for an essentially unlimited range of applications. What purpose does it serve to try to guess a priori what somebody might want to use any particular feature for? But, ruffled feathers aside, it's not at all hard to envision a whole passel of experimental data of different measures wanted to be interpolated to a common base and I've certainly used it in that context. --
 Subject: Why is interp1(x,Y,...) being removed? From: dpb Date: 12 Oct, 2012 21:35:17 Message: 21 of 54 On 10/12/2012 4:05 PM, dpb wrote: ... > Far better would be to release the new functions as either consistent in > effects w/ the old one (only making internal changes iow) or to > introduce them as new functions,... And, of course, it's acceptable to _add_ functionality to an existing function as long as it is in addition too and doesn't remove or change the existing usage. --
 Subject: Why is interp1(x,Y,...) being removed? From: Bruno Luong Date: 12 Oct, 2012 22:19:10 Message: 22 of 54 "Penny Anderson" wrote in message ... > Can you please tell us a little bit more about what kinds of problems you > are using interp1 to solve in this way? > Might be you can ask the person TMW who originally designs the INTERP1? A simple examples is a series of images recorded at (t1, t2, ...), then we want to interpolate to a series of image of (ti1, ti2, ...). Beside that it allows to vectorize the 1D interpolation, where the binning steps and finding weight can be done once. Bruno
 Subject: Why is interp1(x,Y,...) being removed? From: Steven_Lord Date: 12 Oct, 2012 22:27:16 Message: 23 of 54 Let me preface my reply by saying that what I've written is just my take on this situation. I'm taking off my MathWorks hat for the rest of this post. "dpb" wrote in message news:k5a0mu$2em$1@speranza.aioe.org... > On 10/12/2012 2:32 PM, Penny Anderson wrote: >> "james bejon" wrote in message >> news:k54nd8$mcf$1@newscl01ah.mathworks.com... > ... > >>> At the very least, you'd think that TMW could create a function which >>> sets a persistent variable that makes sure everything runs as per a >>> certain release. Then, at the top of a file, I could call, say, >>> runAsPerVersion('2010a') and I'd be done... > ... > >> That would quickly become an intractable problem for MathWorks to >> essentially support k thousand functions * n releases, including all the >> possible combinations, particularly if allowed on a per file basis as >> you suggest. The balance between compatibility and progress is well >> understood, both the pains and benefits, I am afraid. I want to assure >> you that we weigh each item seriously before phasing in a change. We >> don't always get it right, and that's why feedback from customers is so >> valuable. > > I will agree to that not being tractable but it wouldn't be an issue if > weren't so seemingly hellbent on breaking things that don't need to be > broke. > > Why not do the asking _before_ the releasing? Except in rare circumstances, MathWorks does! If you look at the Release Notes for the item that started this thread, you will see that its entry in the R2012a table (which was released in March of this year IIRC, seven months ago) indicates that it still runs in release R2012a: "interp1(x,V,..) where x is a vector and V is an array representing multiple value sets. For example: x = (1:5)'; V = [x, 2*x, 3*x]; xq = (1:0.5:5)'; Vq = interp1(x, V, xq); [What Happens When You Use This Functionality] Still Runs" and that is not listed as having changed in release R2012b. [I just confirmed that the code I pasted above DOES work in R2012b.] In the future MathWorks may remove support for that functionality and make it warn or error, but since the next scheduled release is release R2013a users have at least that long, two full releases (change announced in R2012a, still works in R2012b) warning of the change. During that time they can provide feedback on the announced change to MathWorks. And it is rare, but on occasion MathWorks has announced a planned removal or change of functionality like this and later changed its minds based on user feedback. The Languages and Programming section of the R2012b Release Notes includes one such example (or rather six.) "The R2010a Release Notes originally stated that the isstr, setstr, str2mat, strread, strvcat, and textread functions would be removed in a future release. As of R2012b, there are no plans to remove these functions. However, use of these functions is not recommended." > The "balance" as you call it between compatibility and progress appears to > be weighted heavily towards TMW's viewpoint as opposed to that of > customers. > >> However, I do want to let you and other folks using unique and the other >> set functions that we did provide a limited way to get what you want. > ... > > Far better would be to release the new functions as either consistent in > effects w/ the old one (only making internal changes iow) or to introduce > them as new functions, not replacing them and destroying previous work of > and making more work for your customers. Let's do a little experiment. As part of that experiment, starting right now, you can't read the MATLAB documentation or help text until the experiment is complete. Okay, now the experiment is this: two functions for locating one string inside another are called STRFIND and FINDSTR. One has functionality the other does not. WITHOUT reviewing the documentation or help for these functions, which one has functionality the other does not and what is that functionality? Were you able to successfully answer that question? I probably wouldn't remember the difference off the top of my head (of course, I work with numbers much more than with strings, but still...) There are already hundreds or thousands of functions in MATLAB (leaving alone MathWorks toolboxes or user-created toolboxes.) I doubt anyone remembers what _all_ of those functions do (I know that I do not.) Introducing two functions that do very-similar-but-slightly-different operations would make it even harder to remember the specific function you need to use and would increase the learning curve for new users. The experiment is complete; you may now resume reading the documentation. [The answer to the question: FINDSTR finds the shorter string in the longer, even if the first string is shorter. From http://www.mathworks.com/help/matlab/ref/findstr.html "Unlike the strfind function, the order of the input arguments to findstr is not important. This can be useful if you are not certain which of the two input strings is the longer one."] > At worst you can deprecate usage and cease to upgrade functions but this > idea of either removing them entirely or emasculating them as in the > interp1 behavior that began this thread or simply making their behavior > different but otherwise indistinguishable from which is possibly the most > insidious change since it could cause silent error (S Lord mentioned > earlier today about the "wrong answers fast" syndrome; this could be > "wrong answers silently") is just a terrible path to embark down. > > Another example I've used in the past is textread() -- to the best of my > knowldege there's no longer a way to do what it can do and return an array > instead of a cell w/ a non-deprecated function. As I mentioned above, the Release Notes indicate there are no plans to remove TEXTREAD anymore. I believe that decision was prompted, in part, on user feedback. > That just seems retrogressive and for what purpose? If you don't want to > maintain it any longer, fine--just keep it as is but don't remove it from > the distribution--at least w/o introducing the unique (so to speak :) ) > features it has into something else. Leaving a function around still requires maintenance. It would still need to be tested to ensure that other changes to the language didn't break the "as is" function. It still requires source code to be present in MATLAB for the function. I'm reminded of a couple of quotes listed in Sutter and Alexandrescu's "C++ Coding Standards" item 6: "The cheapest, fastest and most reliable components of a computer system are those that aren't there." -- Gordon Bell (http://en.wikipedia.org/wiki/Gordon_Bell) "Those missing components are also the most accurate (they never make mistakes), the most secure (they can't be broken into), and the easiest to design, document, test and maintain. The importance of a simple design can't be overemphasized." -- Jon Bentley (http://en.wikipedia.org/wiki/Jon_Bentley) > I bring yet again to your attention the much more serious consideration of > compatibility of the Fortran Standards group in only breaking things that > were entirely impossible to maintain or removing features that were almost > universally agreed to have been bad decisions. The thing the customer > base has to protect them there is a consortium and a worldwide > review/balloting process. I'm certainly not saying TMW can open up Matlab > that much but certainly it needs imo somebody advocating more strongly for > the customer base and stability than is presently occurring. It's a tough balancing act -- sometimes users clamor for new functionality but sometimes those same users clamor for everything to stay the same. I don't know what the right answer is, or even if there IS a right answer. I do know that there are a couple of avenues by which You (in this case I'm using the royal you :) can provide that feedback and advocacy to MathWorks.     When a prerelease for a new release comes out, read the Release Notes. Try it out. Run a few of your functions or scripts on it and see if anything major has broken in your code. If it has, or if you have concerns, contact Technical Support.     Post to CSSM and to MATLAB Answers as Richard did.     Sign up for usability testing (http://www.mathworks.com/products/usability/index.html?s_cid=contact_us_support_usability)     If you encounter MathWorks staff attending an event (conference, trade show, etc.) talk to them! You can see a list of some upcoming events here: http://www.mathworks.com/company/events/ -- Steve Lord [Places his MathWorks hat back on his head and gets ready to leave for the weekend.] Good night, everyone.
 Subject: Why is interp1(x,Y,...) being removed? From: Mark Shore Date: 12 Oct, 2012 22:29:14 Message: 24 of 54 Penny, I use interp1 to resample vectors consisting of several million measurement data points. It doesn't bother me if Mathworks adds new functions. It doesn't bother me if Mathworks quietly fixes bugs or tweaks algorithms or code for speed or memory use, as long as the results are correct. This is presumably what I pay annual maintenance fees for. But why would I or any user *want* to have existing functions removed? Such changes lead to needless work involving rewriting and testing code which in my case would amount to time that I cannot charge to projects and that would take away from things I'd rather be doing.
 Subject: Why is interp1(x,Y,...) being removed? From: dpb Date: 13 Oct, 2012 00:02:07 Message: 25 of 54 On 10/12/2012 5:27 PM, Steven_Lord wrote: > Let me preface my reply by saying that what I've written is just my take > on this situation. I'm taking off my MathWorks hat for the rest of this > post. > > "dpb" wrote in message > news:k5a0mu$2em$1@speranza.aioe.org... ... >> Why not do the asking _before_ the releasing? > > Except in rare circumstances, MathWorks does! > > If you look at the Release Notes for the item that started this thread, > you will see that its entry in the R2012a table (which was released in > March of this year IIRC, seven months ago) indicates that it still runs > in release R2012a: ... > In the future MathWorks may remove support for that functionality and > make it warn or error, but since the next scheduled release is release > R2013a users have at least that long, two full releases (change > announced in R2012a, still works in R2012b) warning of the change. > During that time they can provide feedback on the announced change to > MathWorks. And it is rare, but on occasion MathWorks has announced a > planned removal or change of functionality like this and later changed > its minds based on user feedback. The Languages and Programming section > of the R2012b Release Notes includes one such example (or rather six.)  > > "The R2010a Release Notes originally stated that the isstr, setstr, > str2mat, strread, strvcat, and textread functions would be removed in a > future release. As of R2012b, there are no plans to remove these > functions. However, use of these functions is not recommended." It's the (relative) rareness that bugs me and the need to raise such a hullabaloo to begin with that (imo) shouldn't be necessary if the ramifications were more carefully thought through first. ... >> Far better would be to release the new functions as either consistent >> in effects w/ the old one (only making internal changes iow) or to >> introduce them as new functions, not replacing them and destroying >> previous work of and making more work for your customers. > > Let's do a little experiment. As part of that experiment, starting right > now, you can't read the MATLAB documentation or help text until the > experiment is complete. > > > Okay, now the experiment is this: two functions for locating one string > inside another are called STRFIND and FINDSTR. One has functionality the > other does not. WITHOUT reviewing the documentation or help for these > functions, which one has functionality the other does not and what is > that functionality? > > Were you able to successfully answer that question? I probably wouldn't > remember the difference off the top of my head (of course, I work with > numbers much more than with strings, but still...) > > There are already hundreds or thousands of functions in MATLAB (leaving > alone MathWorks toolboxes or user-created toolboxes.) I doubt anyone > remembers what _all_ of those functions do (I know that I do not.) > Introducing two functions that do very-similar-but-slightly-different > operations would make it even harder to remember the specific function > you need to use and would increase the learning curve for new users. ... Well, it's a loaded question for me, Steve, as I don't have the release that introduced the new one so I've not had the chance to latch onto the specific change(s) by memory. I do agree the problem of namespace pollution/proliferation is a serious one with Matlab. Given the purpose I don't see any great way to help a lot on the numbers and I do think the introduction willy-nilly of similar-named functions is not _a_good_thing_ (tm). _But_, the "added functionality" is actually the historic Matlab behavior as it is findstr() that is the initial function and strfind() that doesn't mimic that that is the new introduction. And, the current documentation also says "findstr is not recommended. Use strfind instead." so it's hardly on equal footing with strfind() any longer. Any time I see something like that in the documentation I fear it is simply a precursor of saying "deprecated; will be removed in a future release" at any time TMW decides they want to. It would seem to me at least superficially w/o trying to write the extra/revised behavior into that of the existing findstr() that the better path rather than to introduce the flipped-name version would to have used a new optional flag to tell findstr() to return the empty string if the pattern is longer than (BTW, there's a typo in the last sentence before the Examples section of a "then" instead of "than") the string(s) to search. Then the user has the option of either behavior as wanted w/o the need for the second confusing function name. It seems that I recall there being at least some mention on this before that the strfind() name was introduced at least in part to try to make it more conforming to the other strXXX functions. Why it wasn't named that way in the beginning is undoubtedly lost in the mists of history. IIRC, that had to do w/ a similar discussion on why removing findstr instead of simply deprecating its use. Yet here you've made an argument (acknowledged as the individual and not TMW) for why the original shouldn't be dropped because it does, indeed, have a functionality that users may have built code around. > As I mentioned above, the Release Notes indicate there are no plans to > remove TEXTREAD anymore. I believe that decision was prompted, in part, > on user feedback. ... > > Leaving a function around still requires maintenance. It would still > need to be tested to ensure that other changes to the language didn't > break the "as is" function. It still requires source code to be present > in MATLAB for the function. I'm reminded of a couple of quotes listed in > Sutter and Alexandrescu's "C++ Coding Standards" item 6: > > "The cheapest, fastest and most reliable components of a computer system > are those that aren't there." -- Gordon Bell > (http://en.wikipedia.org/wiki/Gordon_Bell) > > "Those missing components are also the most accurate (they never make > mistakes), the most secure (they can't be broken into), and the easiest > to design, document, test and maintain. The importance of a simple > design can't be overemphasized." -- Jon Bentley > (http://en.wikipedia.org/wiki/Jon_Bentley) Both of those are true, but they're only one side of the story--essentially from the viewpoint of the vendor, not the vendor's customer base. W/ the assumption the customer isn't doing something that isn't needed (perhaps a false one in some instances, but surely not a general rule) the removal from the base product simply shifts the burden for implementing that functionality to the end user instead of having it in the development environment. It's that richness of the environment that is the selling point and purpose of having a Matlab-like system in the first place--if the vendor insists on making the content supplied fit what is convenient for them instead of what is useful, there is less and less impetus to use the product. Certainly having to modify/repair/debug/test working code because something has been changed is not conducive to rapid development. In my view, TMW took on that burden w/ the base language and the toolboxes when they chose that as the product to market and it's their responsibility as a reliable vendor to keep that environment as stable as possible. >> I bring yet again to your attention the much more serious >> consideration of compatibility of the Fortran Standards group in only >> breaking things that were entirely impossible to maintain or removing >> features that were almost universally agreed to have been bad >> decisions. The thing the customer base has to protect them there is a >> consortium and a worldwide review/balloting process. I'm certainly not >> saying TMW can open up Matlab that much but certainly it needs imo >> somebody advocating more strongly for the customer base and stability >> than is presently occurring. > > It's a tough balancing act -- sometimes users clamor for new > functionality but sometimes those same users clamor for everything to > stay the same. I don't know what the right answer is, or even if there > IS a right answer. I do know that there are a couple of avenues by which > You (in this case I'm using the royal you :) can provide that feedback > and advocacy to MathWorks. > > When a prerelease for a new release comes out, read the Release Notes. > Try it out. Run a few of your functions or scripts on it and see if > anything major has broken in your code. If it has, or if you have > concerns, contact Technical Support. ... My viewpoint is still that it is TMW's job to ensure they don't break my code first by making changes in syntax or functionality. After that I'll test for consistency between releases (just as do when upgrade a compiler). But I surely expect to only _VERY_ rarely have to actually change code simply because the equivalent of the compiler has been updated. Now, if there were such a thing as a vendor-extension to the Matlab Standard and I were to switch vendors, that's a whole different story. As alluded to earlier, though, since Matlab is a proprietary system users are dependent on TMW being a good and benevolent Standards authority unilaterally and that's a risky position at best with mission-critical code. --
 Subject: Why is interp1(x,Y,...) being removed? From: dpb Date: 13 Oct, 2012 01:22:10 Message: 26 of 54 On 10/12/2012 7:02 PM, dpb wrote: > On 10/12/2012 5:27 PM, Steven_Lord wrote: ... >> As I mentioned above, the Release Notes indicate there are no plans to >> remove TEXTREAD anymore. I believe that decision was prompted, in part, >> on user feedback. > ... >> ... OK, that is indeed _a_good_thing_ (tm) and it is gratifying to note that at least occasionally users can stop the runaway freight train. I'm not sure how much credit I can take altho I know I certainly have harped on it a lot... :) So, now I'll stop now that it is apparently officially removed from the endangered species list. I had noticed the verbiage in the online documentation had changed at least slightly altho I wasn't sure whether one could actually put much reliance on that. I will admit I don't read release notes since I don't have any plans to actually update--I do use the online doc's a fair amount in responding here when I'm not confident if current behavior still matches my release (and, it's a telling statement that one has to be concerned about that for existing functions in my view and not a positive one at all). New features and enhancements and even new functions/datatypes/etc. are all well and good and one thing but breaking working code is something else again and is rarely ever justified imo and certainly not for trivial stuff that is clearly useful as in the subject of this thread. Somewhat like some of the "features" of the new help design, I just can't fathom how it could have gotten any traction at all as an idea, what more actually make it to the level of a release note. It reinforces in my mind the fact that compatibility really just doesn't rank very high on the list of priorities in the decision process because if it did that would be the first thing internal review inside TMW would flag and stop it from happening before the outside world ever knew anything about it. --
 Subject: Why is interp1(x,Y,...) being removed? From: Bruno Luong Date: 13 Oct, 2012 07:32:12 Message: 27 of 54 dpb wrote in message ... > It > reinforces in my mind the fact that compatibility really just doesn't > rank very high on the list of priorities in the decision process because > if it did that would be the first thing internal review inside TMW would > flag and stop it from happening before the outside world ever knew > anything about it. It looks like maintainability effort (by TMW) ranks higher than compatibility as Steve explains. I don't understand this decision (actually I think I do). INTERP1 is a function that exists longtime, it should a some point become stable. I assume it is the case by now. Maintaining as it is requires almost zero effort on the TMW side, unless if they want to improve it (such as enhance performance, add new feature, ...). They must have strong reason to want to remove it I guess. One of the the reason is may be they developed a new requirement for MATLAB functions in a larger project, and INTERP1 no longer fulfill this requirement. But that we don't know and I think users like us will not be informed by this kind of decision. From my experience, this kind of situation happens everywhere, not only at TMW. When the people who originally developed a piece of code are gone, new people jumps in and try replace it because they don't know how to maintain it cheaply. Bruno
 Subject: Why is interp1(x,Y,...) being removed? From: Matt J Date: 13 Oct, 2012 10:45:08 Message: 28 of 54 "Bruno Luong" wrote in message ... > dpb wrote in message ... > > It > > reinforces in my mind the fact that compatibility really just doesn't > > rank very high on the list of priorities in the decision process because > > if it did that would be the first thing internal review inside TMW would > > flag and stop it from happening before the outside world ever knew > > anything about it. > > It looks like maintainability effort (by TMW) ranks higher than compatibility as Steve explains. I don't understand this decision (actually I think I do). > > INTERP1 is a function that exists longtime, it should a some point become stable. I assume it is the case by now. Maintaining as it is requires almost zero effort on the TMW side, unless if they want to improve it (such as enhance performance, add new feature, ...). > > They must have strong reason to want to remove it I guess. One of the the reason is may be they developed a new requirement for MATLAB functions in a larger project, and INTERP1 no longer fulfill this requirement. But that we don't know and I think users like us will not be informed by this kind of decision. > > From my experience, this kind of situation happens everywhere, not only at TMW. When the people who originally developed a piece of code are gone, new people jumps in and try replace it because they don't know how to maintain it cheaply. ================ To me, that doesn't really explain things. You can reimplement a function to ease maintenance without changing its I/O behavior for the user.
 Subject: Why is interp1(x,Y,...) being removed? From: Bruno Luong Date: 13 Oct, 2012 12:15:08 Message: 30 of 54 "Matt J" wrote in message ... > To me, that doesn't really explain things. You can reimplement a function to ease maintenance without changing its I/O behavior for the user. Think might get more complex that just user interface. I give a simple fantasy example here  Up to now, MATLAB is mostly a single process program. There is no need for any function (such as interp1) to be thread safe. Suppose for a moment TMW decides to have multi-process capability, and have a big development on that, they must bring INTERP1 up-to-date. Now those people who have developed INTERP1 are gone, they might start all over again and develop a NewFancyButBuggySingleVectorInterp1 to replace the old one. Development scheduling is too short, so NewFancyButBuggySingleVectorInterp1 can't support the syntax: NewFancyButBuggySingleVectorInterp1(x,Y) So the shortcut is issuing a warning for few millions users, delete the INTERP1 and add NewFancyButBuggySingleVectorInterp1 in 2013A. Bruno
 Subject: Why is interp1(x,Y,...) being removed? From: Matt J Date: 13 Oct, 2012 12:58:07 Message: 31 of 54 "Bruno Luong" wrote in message ... > "Matt J" wrote in message ... > > To me, that doesn't really explain things. You can reimplement a function to ease maintenance without changing its I/O behavior for the user. > > Think might get more complex that just user interface. I give a simple fantasy example here > > Up to now, MATLAB is mostly a single process program. There is no need for any function (such as interp1) to be thread safe. Suppose for a moment TMW decides to have multi-process capability, and have a big development on that, they must bring INTERP1 up-to-date. Now those people who have developed INTERP1 are gone, they might start all over again and develop a NewFancyButBuggySingleVectorInterp1 to replace the old one. Development scheduling is too short, so NewFancyButBuggySingleVectorInterp1 can't support the syntax: > > NewFancyButBuggySingleVectorInterp1(x,Y) > > So the shortcut is issuing a warning for few millions users, delete the INTERP1 and add NewFancyButBuggySingleVectorInterp1 in 2013A. ================= Then the solution would be to re-implement INTERP1 without multi-threading, so that the development timeline is shorter. Or, alternatively, to set a longer development timeline and release interp1 only when it supports all the old I/O options. No, I don't see why any new capability has to go into an old function. capability has to go into an old function.
 Subject: Why is interp1(x,Y,...) being removed? From: Bruno Luong Date: 13 Oct, 2012 13:17:09 Message: 32 of 54 "Matt J" wrote in message ... > > Then the solution would be to re-implement INTERP1 without multi-threading, so that the development timeline is shorter. New development should progress to cope with hardware' changes. > Or, alternatively, to set a longer development timeline and release interp1 only when it supports all the old I/O options. Hah, that's a (big buck) problem, and might be you are pointing the finger to the real problem. Timeline has stronger priority than compatibility for few sale managers out there. How do you understand when Steve said that interp1() is no longer maintained and not recommended ? I interpret it as they won't any effort on this old piece of code to save money. Bruno
 Subject: Why is interp1(x,Y,...) being removed? From: Steven_Lord Date: 15 Oct, 2012 15:19:09 Message: 33 of 54 "Bruno Luong" wrote in message news:k5bpkl$qvc$1@newscl01ah.mathworks.com... > "Matt J" wrote in message ... > >> >> Then the solution would be to re-implement INTERP1 without >> multi-threading, so that the development timeline is shorter. > > New development should progress to cope with hardware' changes. > >> Or, alternatively, to set a longer development timeline and release >> interp1 only when it supports all the old I/O options. > > Hah, that's a (big buck) problem, and might be you are pointing the finger > to the real problem. Timeline has stronger priority than compatibility for > few sale managers out there. While the timeline is and IMO should be a consideration in the development process (see: Duke Nukem Forever, the term 'vaporware', the 'project triangle') in my experience here at MathWorks it's not the only one. > How do you understand when Steve said that interp1() is no longer > maintained and not recommended ? I interpret it as they won't any effort > on this old piece of code to save money. Stop. Nothing in the Release Notes nor in this thread indicate that INTERP1 is going away. _Certain specific calling syntaxes_ for INTERP1 have been announced in the Release Notes as being removed or changed. The _function as a whole_ has not been announced as being removed or changed. For the particular change that started this thread, let's take a look at the section of the documentation that describes the implications of that syntax. " If Y is a vector, it must have the same length as x. A scalar value for Y is expanded to have the same length as x. xi can be a scalar, a vector, or a multidimensional array, and yi has the same size as xi.     If Y is an array that is not a vector, the size of Y must have the form [n,d1,d2,...,dk], where n is the length of x. The interpolation is performed for each d1-by-d2-by-...-dk value in Y. The sizes of xi and yi are related as follows:         If xi is a scalar or vector, size(yi) equals [length(xi), d1, d2, ..., dk].         If xi is an array of size [m1,m2,...,mj], yi has size [m1,m2,...,mj,d1,d2,...,dk]." If this change were to go through, I _think_ this section of the documentation would become something like: "Y must be a vector of the same size as x or must be a scalar. yi is the same size as xi." This makes it a lot easier to understand what INTERP1 is actually going to give you. I haven't looked through the INTERP1 code recently but I expect this change would also simplify the code and probably improve performance in the case where x and y are both vectors, which I believe is a MUCH, MUCH more common usage of INTERP1. Instead of spending a dozen lines of code computing whether Y was the correct size to trigger this behavior and carrying that information through the function, INTERP1 just has to check "Are x and y the same size? If not, error out." and then the rest of the code can rely upon that fact. -- Steve Lord slord@mathworks.com To contact Technical Support use the Contact Us link on http://www.mathworks.com
 Subject: Why is interp1(x,Y,...) being removed? From: Steven_Lord Date: 15 Oct, 2012 15:34:33 Message: 34 of 54 "dpb" wrote in message news:k5a197$3re$1@speranza.aioe.org... > On 10/12/2012 2:23 PM, Penny Anderson wrote: > ... > >> Can you please tell us a little bit more about what kinds of problems >> you are using interp1 to solve in this way? > > Why should customers (present or future) have to justify their usage to > TMW? 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. http://en.wikipedia.org/wiki/Use_case > The point of Matlab is to be a general-purpose toolset for an essentially > unlimited range of applications. What purpose does it serve to try to > guess a priori what somebody might want to use any particular feature for? Identifying functional requirements. http://en.wikipedia.org/wiki/Functional_requirement -- Steve Lord slord@mathworks.com To contact Technical Support use the Contact Us link on http://www.mathworks.com
 Subject: Why is interp1(x,Y,...) being removed? From: Richard Crozier Date: 15 Oct, 2012 15:59:08 Message: 35 of 54 "Steven_Lord" wrote in message ... > > 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? 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.
 Subject: Why is interp1(x,Y,...) being removed? From: Steve Eddins Date: 15 Oct, 2012 16:53:55 Message: 36 of 54 On 10/15/2012 11:59 AM, Richard Crozier wrote:> [snip]  >  > 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. Your assumption about our reason for making this change is false. With MATLAB 7 (2004), MathWorks introduced a new way to deal with extra arguments to ODE solvers (and, in general, other functions that operate on functions). Some of the reasons are described in a document that I wrote back in 2003. The document attempted to motivate the introduction of nested functions and anonymous function handles. Below is a plain-text approximation of section 1 of that document. Section 1.1 includes a specific list of problems related to the old "P1,P2,..." syntax I believe you are talking about. Steve === Document excerpt === 1.0 PROBLEMS ADDRESSED The proposed language changes address several related problems with function functions (funfuns) and inline objects. The problems have existed for many years. Symptoms range from basic user confusion to slow performance to overly complex function syntaxes. 1.1 Problems with funfuns Function arguments (funargs) passed into a funfun often depend on parameters that the funfun doesn’t know or care about. For example, suppose you want to use quad to compute \int_0^{2\pi} v(t) dt, where v(t) = g cos(\omega t). Although the variable of integration is t, v(t) also depends on the parameters g and \omega. (example 1) We have a standard practice for handling additional parameters in funfuns. This practice, illustrated in examples 1, 2, 6, and 8, has several weaknesses addressed by this proposal: * The current practice is difficult to understand, and users make common errors. (examples 1, 2, 3, 4, and 6; see also comp.soft-sys.matlab, which has about a posting per week on this topic.) * Funfun syntax is difficult to design. (example 8) * Once created, a funfun is difficult or impossible to extend in a compatible way. (example 8) * Funfuns can be run efficiently only when the funarg is in the form of an M-file. (This is related to the implementation of inline objects in terms of eval. * The current practice for handling parameter passing when a funfun accepts more than one funarg is awkward, even embarrassing. (examples 6 and 8) * The current practice does not support safe and efficient data or computation sharing among funargs. (example 9) * Implementation of parameter passing using varargin hinders performance optimizations. (See the “Efficiency” appendix in the spec document.) 1.2 Problems with inline objects Inline objects were introduced in MATLAB 5 as a way to create pseudofunctions “on-the-fly.” They are frequently used as inputs to funfuns. For example:  >> f = inline(’x.^2’);  >> quad(f, 0, 1)    ans =    0.3333 Inline objects have several significant problems: * Users are often confused about how to use inline objects. In particular, they commonly make these two mistakes: ** Users expect to be able to compose inline objects (define one in terms of another). (example 5) ** Users expect inline objects formed at the prompt to have access to base workspace variables. (examples 1, 2, 3, and 4) In both cases, the error messages come from the bowels of inline’s overloaded operator methods and do not help the user understand what is wrong. * Expression-based inline objects are implemented by using eval in an overloaded subsref method. As a result, code that uses expression-based inline objects is: ** slow ** unoptimizable (un-jit-able, untransformable, uncompilable) -- Steve Eddins http://blogs.mathworks.com/steve/ -- Steve Eddins http://blogs.mathworks.com/steve/
 Subject: Why is interp1(x,Y,...) being removed? From: Steven_Lord Date: 15 Oct, 2012 16:59:56 Message: 37 of 54 "Richard Crozier" wrote in message news:k5hbsc$gbs$1@newscl01ah.mathworks.com... > "Steven_Lord" wrote in message > ... > >> >> 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 slord@mathworks.com To contact Technical Support use the Contact Us link on http://www.mathworks.com
 Subject: Why is interp1(x,Y,...) being removed? From: dpb Date: 15 Oct, 2012 17:45:49 Message: 38 of 54 On 10/15/2012 10:34 AM, Steven_Lord wrote: > "dpb" wrote in message > news:k5a197$3re$1@speranza.aioe.org... >> On 10/12/2012 2:23 PM, Penny Anderson wrote: >> ... >>> Can you please tell us a little bit more about what kinds of problems >>> you are using interp1 to solve in this way? >> >> Why should customers (present or future) have to justify their usage >> to TMW? > > 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. ... Well, if it were new usage I could see it perhaps but having to justify/enumerate to keep existing usage just seems like having to beg to me...and _SURELY_ the idea of having multiple datasets to interpolate to a common base at a time can't be _that_ much of a stretch (particularly again since the facility was envisioned in the original release) can it???? If it truly were so, I must question the breadth of the universe polled in the decision-making process that couldn't foresee/envision it. --
 Subject: Why is interp1(x,Y,...) being removed? From: Richard Crozier Date: 15 Oct, 2012 18:05:10 Message: 39 of 54 "Steven_Lord" wrote in message ... > > > "Richard Crozier" wrote in message > news:k5hbsc$gbs$1@newscl01ah.mathworks.com... > > "Steven_Lord" wrote in message > > ... > > > >> > >> 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 > slord@mathworks.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.
 Subject: Why is interp1(x,Y,...) being removed? From: dpb Date: 15 Oct, 2012 18:22:24 Message: 40 of 54 On 10/15/2012 12:45 PM, dpb wrote: > On 10/15/2012 10:34 AM, Steven_Lord wrote: >> "dpb" wrote in message >> news:k5a197$3re$1@speranza.aioe.org... >>> On 10/12/2012 2:23 PM, Penny Anderson wrote: >>> ... >>>> Can you please tell us a little bit more about what kinds of problems >>>> you are using interp1 to solve in this way? >>> >>> Why should customers (present or future) have to justify their usage >>> to TMW? >> >> 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. > > ... > > Well, if it were new usage I could see it perhaps but having to > justify/enumerate to keep existing usage just seems like having to beg > to me...and _SURELY_ the idea of having multiple datasets to interpolate > to a common base at a time can't be _that_ much of a stretch > (particularly again since the facility was envisioned in the original > release) can it????... And, I'll reiterate again (again, :) ) that it gratuitously breaks user code unilaterally for no justifiable reason and throws work upon them that shouldn't be there. The compatibility issue alone should have made it a non-starter from the git-go alleviating the need for the entire thread, the investment in/at TMW and the burden on users of having to fight to retain something they already had. Again, compatibility just doesn't seem to rate nearly as high on the scale when push comes to shove as do apparently some inside TMW think it does. --
 Subject: Why is interp1(x,Y,...) being removed? From: Steve Eddins Date: 15 Oct, 2012 19:25:11 Message: 41 of 54 On 10/15/2012 2:05 PM, Richard Crozier wrote:  > [snip] > 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. "Too confusing for users" is not anything like what you said, facetiously or otherwise. You said that "[we at MathWorks] have decided users are too stupid to understand the feature." Confusion over the behavior of the old-style syntaxes was widespread among users of all skill and experience levels. That indicates a problem with the software design, not a problem with the users. Steve Lord and I are two different people, by the way. -- Steve Eddins http://blogs.mathworks.com/steve/
 Subject: Why is interp1(x,Y,...) being removed? From: Bruno Luong Date: 15 Oct, 2012 20:11:14 Message: 42 of 54 IMO: - INTERP1 flexible syntax is OK - INTERP1 is bad performance wise - INTERP1 bad performance is not due to flexible syntax, but because it is poorly implemented - Some folks at TMW now push to replace old-style syntax with OOP syntax of existing functionality. Fine with me. - They must fix a goal of enhancing the performance of INTERP1. This task should not be very hard. - They must NOT change calling syntax of INTERP1 - They should not distance with the old syntax style with the new command. Replacing operation on array with a for-loop is clearly a regression. MATLAB is great when you don't have to think about details about looping, etc... Please take a look at the example an syntax changes recommended by TMW [highlight of the release note] : % old style Vq = interp1(x, V, xq); % should be changed to F = griddedInterpolant(x, V(:,1)); for n=1:3   F.Values = V(:, n);   Vq(:, n) = F(xq); end % You call the later clearer? less confusing? Not really IMO. Bruno
 Subject: Why is interp1(x,Y,...) being removed? From: dpb Date: 15 Oct, 2012 22:07:35 Message: 43 of 54 On 10/15/2012 11:59 AM, dpb wrote: ... > ... the section that > describes what's being removed in my release simply says > >> yi = interp1(x,Y,xi) returns vector yi containing elements >> corresponding to the elements of xi and determined by interpolation >> within vectors x and Y. The vector x specifies the points at which the >> data Y is given. If Y is a matrix, then the interpolation is >> performed for each column of Y and yi is length(xi)-by-size(Y,2). > > I've certainly never had any problem in understanding that given a > single vector X of independent values that any complementary array of > Y's would have to have the corresponding correct size nor what the > result was going to be. > > Certainly there are any number of other functions that operate by column > in Matlab so it's hardly a unique concept to interp1(). OK, the above could stand some editing, too, but it could certainly be clarified to handle the case of Y being a vector or array far more succinctly than the current version. I'd basically just recast the first sentence above to say yi returns a vector or array dependent upon whether Y is a vector or array. Perhaps simply having to paragraphs even that describe the two cases independently but it certainly doesn't need anything like the convoluted mess it now is to make it perfectly plain and surely to use the argument that horrible writing in the help justifies removing a very useful capability simply to avoid fixing the help is a perverse at best definition of "compatibility". --
 Subject: Why is interp1(x,Y,...) being removed? From: dpb Date: 16 Oct, 2012 02:52:12 Message: 44 of 54 On 10/15/2012 3:11 PM, Bruno Luong wrote: > IMO: > > - INTERP1 flexible syntax is OK > - INTERP1 is bad performance wise > - INTERP1 bad performance is not due to flexible syntax, but because it > is poorly implemented > - Some folks at TMW now push to replace old-style syntax with OOP syntax > of existing functionality. Fine with me. > - They must fix a goal of enhancing the performance of INTERP1. This > task should not be very hard. > - They must NOT change calling syntax of INTERP1 > - They should not distance with the old syntax style with the new > command. Replacing operation on array with a for-loop is clearly a > regression. MATLAB is great when you don't have to think about details > about looping, etc... ... +1 --
 Subject: Why is interp1(x,Y,...) being removed? From: Ken Garrard Date: 16 Oct, 2012 03:07:21 Message: 45 of 54 "Bruno Luong" wrote in message ... > IMO: > > - INTERP1 flexible syntax is OK > - INTERP1 is bad performance wise > - INTERP1 bad performance is not due to flexible syntax, but because it is poorly implemented > - Some folks at TMW now push to replace old-style syntax with OOP syntax of existing functionality. Fine with me. > - They must fix a goal of enhancing the performance of INTERP1. This task should not be very hard. > - They must NOT change calling syntax of INTERP1 > - They should not distance with the old syntax style with the new command. Replacing operation on array with a for-loop is clearly a regression. MATLAB is great when you don't have to think about details about looping, etc... Please take a look at the example an syntax changes recommended by TMW [highlight of the release note] : > > % old style > Vq = interp1(x, V, xq); > > % should be changed to > F = griddedInterpolant(x, V(:,1)); > for n=1:3 > F.Values = V(:, n); > Vq(:, n) = F(xq); > end > > % You call the later clearer? less confusing? Not really IMO. > > Bruno The suggested new syntax is definitely NOT clearer. But if you look inside the interp1 function in R2012b you'll see calls to griddedInterpolant. This wasn't the case a couple of years ago. I haven't checked to see if the new version is more or less efficient or produces the identical results for the same inputs. So why get rid of interp1 if it's already implementing the change suggested for our code? I frequently use interp1 for metrology data. Multiple measurements are never at exactly the same spacing and a single measurement data set is never at exactly the same points as the design. So it's common (and necessary) to interpolate before subtracting measured_Y from design_Y. It makes no sense to do so if the X's are different. I'm also working with very large imaging mass spectrometry data sets where the m/z values for each pixel's data cube are sparsely and irregularly spaced. The range of values at a pixel might be between 200 and 2000 Daltons with a minimum spacing of 1e-5, but contain only 50k irregularly spaced data points. The next pixel has the same range and resolution, but data points at different m/z values. Yesterday I ran grep on the toolbox folder for R2012b searching for "interp1" in *.m files. I have the optimization, image processing, statistics and bioinformatics toolboxes installed. There were 137 hits. Ken
 Subject: Why is interp1(x,Y,...) being removed? From: dpb Date: 16 Oct, 2012 03:09:53 Message: 46 of 54 On 10/15/2012 10:19 AM, Steven_Lord wrote: ... > If Y is an array that is not a vector, the size of Y must have the form > [n,d1,d2,...,dk], where n is the length of x. The interpolation is > performed for each d1-by-d2-by-...-dk value in Y. The sizes of xi and yi > are related as follows: > > If xi is a scalar or vector, size(yi) equals [length(xi), d1, d2, ..., dk]. > > If xi is an array of size [m1,m2,...,mj], yi has size > [m1,m2,...,mj,d1,d2,...,dk]." > > > If this change were to go through, I _think_ this section of the > documentation would become something like: > > > "Y must be a vector of the same size as x or must be a scalar. yi is the > same size as xi." > > > This makes it a lot easier to understand what INTERP1 is actually going > to give you. I haven't looked through the INTERP1 code recently but I > expect this change would also simplify the code and probably improve > performance in the case where x and y are both vectors, which I believe > is a MUCH, MUCH more common usage of INTERP1. Instead of spending a > dozen lines of code computing whether Y was the correct size to trigger > this behavior and carrying that information through the function, > INTERP1 just has to check "Are x and y the same size? If not, error > out." and then the rest of the code can rely upon that fact. I can't make heads nor tails of the above but that seems to be a perversion of the original INTERP1 handling an array of Y if it is more than just interpolating for xi over the columns of an array Y that has the same number of rows as length(x). If that is the case that it has been tried to be made even more general somehow, while I detest the idea of losing compatibility for anybody, I could see that a bad decision earlier _might_ be justified to be recanted somewhat. I canNOT condone removing the "simple" array Y case entirely, however. I have no idea what recent source for INTERP1 looks like, of course, but in the older version it is fairly straightforward and not all that much error-checking/input processing required to handle the inputs. I do note on review that I do have a couple of patches in my version that fixup a couple of errors for the array case, however, that I had forgotten having made. These have to do w/ two cases that are in error in setting the size/shape of the output argument for an array input -- the biggest was that if the number of interpolants is fewer than the number of columns in Y the original function returned yi as length() Y instead of size() Y. Obviously I had used the function in a case like that sometime in the past as discussed in the "functional requirements" subthread or I wouldn't have made the patches. --
 Subject: Why is interp1(x,Y,...) being removed? From: Bruno Luong Date: 16 Oct, 2012 07:21:07 Message: 47 of 54 dpb wrote in message ... > > If that is the case that it has been tried to be made even more general > somehow, while I detest the idea of losing compatibility for anybody, I > could see that a bad decision earlier _might_ be justified to be > recanted somewhat. > NO! This reasoning is how the TMW do with INTERP1, which is a wrong doing. Feature should not be removed because of COMPATIBILITY. If the feature is not clear, rewrite the doc. Bruno
 Subject: Why is interp1(x,Y,...) being removed? From: dpb Date: 16 Oct, 2012 13:29:22 Message: 48 of 54 On 10/16/2012 2:21 AM, Bruno Luong wrote: > dpb wrote in message ... >> >> If that is the case that it has been tried to be made even more >> general somehow, while I detest the idea of losing compatibility for >> anybody, I could see that a bad decision earlier _might_ be justified >> to be recanted somewhat. >> > > NO! This reasoning is how the TMW do with INTERP1, which is a wrong > doing. Feature should not be removed because of COMPATIBILITY. If the > feature is not clear, rewrite the doc. Do you understand the latest version fully, Bruno? I can't test what it really does...and so far I don't follow what the doc is trying to say. Is it indeed just terribly poorly written documentation or is there some other functionality actually included now beyond that of simply interpolation on the columns of the array Y? If it is just excessively verbose and rambling description of the latter then I'm in full agreement. On the other, I'm not so adamant--I'd have to have a better appreciation for what that additional feature really does. I would rather there be no regression at all in compatibility, but in rare instances it is better--even my comparison bellweather Fortran was forced to make some changes that broke a few old and generally arcane features in order to be able to progress. --
 Subject: Why is interp1(x,Y,...) being removed? From: Richard Crozier Date: 16 Oct, 2012 14:40:09 Message: 49 of 54 > Do you understand the latest version fully, Bruno? I can't test what it > really does...and so far I don't follow what the doc is trying to say. > > Is it indeed just terribly poorly written documentation or is there some > other functionality actually included now beyond that of simply > interpolation on the columns of the array Y? I haven't actually tried more than 2 dimensions in Y, but I believe it will interpolate datasets in every dimension of Y provided the first dimension is the same length as x, e.g. x = linspace(0,2*pi,10)'; xi = [0,pi/4,pi]'; Y = sin(x); interp1(x, Y, xi) ans =      0.0000e+000    685.5401e-003     55.5112e-018 Y = [sin(x), cos(x)]; interp1(x, Y, xi) ans =      0.0000e+000 1.0000e+000    685.5401e-003 691.9949e-003     55.5112e-018 -939.6926e-003 Y(:,:,1:6) = repmat([sin(x), cos(x)], [1,1,6]); interp1(x, Y, xi) ans(:,:,1) =      0.0000e+000 1.0000e+000    685.5401e-003 691.9949e-003     55.5112e-018 -939.6926e-003 ans(:,:,2) =      0.0000e+000 1.0000e+000    685.5401e-003 691.9949e-003     55.5112e-018 -939.6926e-003 ans(:,:,3) =      0.0000e+000 1.0000e+000    685.5401e-003 691.9949e-003     55.5112e-018 -939.6926e-003 ans(:,:,4) =      0.0000e+000 1.0000e+000    685.5401e-003 691.9949e-003     55.5112e-018 -939.6926e-003 ans(:,:,5) =      0.0000e+000 1.0000e+000    685.5401e-003 691.9949e-003     55.5112e-018 -939.6926e-003 ans(:,:,6) =      0.0000e+000 1.0000e+000    685.5401e-003 691.9949e-003     55.5112e-018 -939.6926e-003 and so on, which is really quite cool functionality as I can imagine arranging my data in a way that was physically meaningful for multiple degrees of freedom.
 Subject: Why is interp1(x,Y,...) being removed? From: dpb Date: 16 Oct, 2012 15:09:30 Message: 50 of 54 On 10/16/2012 9:40 AM, Richard Crozier wrote: ... >> ... is there >> some other functionality actually included now beyond that of simply >> interpolation on the columns of the array Y? > > I haven't actually tried more than 2 dimensions in Y, but I believe it > will interpolate datasets in every dimension of Y provided the first > dimension is the same length as x, > ...[test/sample multi-D code elided for brevity]... > > ... which is really quite cool functionality as I can imagine > arranging my data in a way that was physically meaningful for multiple > degrees of freedom. Indeed, that is pretty kewl. OK, I'm back w/ Bruno on the let's not lose compatibility and TMW needs to basically follow his outline above and then work on the documentation instead of pulling the plug on functionality as the simple path. Imagine the ugliness of implementing the last few of the above w/ the new fancy-smantzy object-based solution. :( --
 Subject: Why is interp1(x,Y,...) being removed? From: Bruno Luong Date: 16 Oct, 2012 18:59:17 Message: 51 of 54 dpb wrote in message ... > > Imagine the ugliness of implementing the last few of the above w/ the > new fancy-smantzy object-based solution. :( > Yeap. I think you get the picture now dpb. One short neat command INTERP1 (admittedly not obvious immediate usage for some) is replaced with a block of 5 commands and a for-loop. :-( Bruno
 Subject: Why is interp1(x,Y,...) being removed? From: dpb Date: 16 Oct, 2012 19:46:13 Message: 52 of 54 On 10/16/2012 1:59 PM, Bruno Luong wrote: > dpb wrote in message ... >> >> Imagine the ugliness of implementing the last few of the above w/ the >> new fancy-smantzy object-based solution. :( >> > > Yeap. I think you get the picture now dpb. One short neat command > INTERP1 (admittedly not obvious immediate usage for some) is replaced > with a block of 5 commands and a for-loop. :-( Well, that picture I got that all along... :) I just hadn't seen the multi-directional case and wasn't aware that it was incorporated into the current release of interp1. It was ugly-enough for that simple first example case, it becomes even more so at those more complex uses. TMW wants to upgrade the documentation; here's another example of the contention I've made all along that the better path to upgrading it is to improve the content and references rather than worrying about the look and feel. --
 Subject: Why is interp1(x,Y,...) being removed? From: Richard Crozier Date: 16 Oct, 2012 20:09:14 Message: 53 of 54 dpb wrote in message ... > On 10/16/2012 1:59 PM, Bruno Luong wrote: > > dpb wrote in message ... > >> > >> Imagine the ugliness of implementing the last few of the above w/ the > >> new fancy-smantzy object-based solution. :( > >> > > > > Yeap. I think you get the picture now dpb. One short neat command > > INTERP1 (admittedly not obvious immediate usage for some) is replaced > > with a block of 5 commands and a for-loop. :-( > > Well, that picture I got that all along... :) > > I just hadn't seen the multi-directional case and wasn't aware that it > was incorporated into the current release of interp1. It was > ugly-enough for that simple first example case, it becomes even more so > at those more complex uses. > > TMW wants to upgrade the documentation; here's another example of the > contention I've made all along that the better path to upgrading it is > to improve the content and references rather than worrying about the > look and feel. > > -- What's missing is a decent set of examples like the one I just presented. There was a single example of this syntax in r2008b, and currently none in r2012a (presumeably since they did not want people to use it any more).
 Subject: Why is interp1(x,Y,...) being removed? From: dpb Date: 16 Oct, 2012 21:10:03 Message: 54 of 54 On 10/16/2012 3:09 PM, Richard Crozier wrote: > dpb wrote in message ... ... >> TMW wants to upgrade the documentation; here's another example of the >> contention I've made all along that the better path to upgrading it is >> to improve the content and references rather than worrying about the >> look and feel. ... > What's missing is a decent set of examples like the one I just > presented. There was a single example of this syntax in r2008b, and > currently none in r2012a (presumeably since they did not want people to > use it any more). I think Steven's point that the verbiage describing the feature is near gibberish is a valid one. That doesn't mean TMW should take the easy way out and simply remove the functionality simply because the documentation isn't very good. Instead the feature description should be recrafted and certainly adding some examples would aid in the interpretation of the explanation. --