Thread Subject:

Why is interp1(x,Y,...) being removed?

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.

"Richard Crozier" wrote in message <k53he7$onf$1@newscl01ah.mathworks.com>...
>
> 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.

"Matt J" wrote in message <k5432l$rc$1@newscl01ah.mathworks.com>...

> 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.

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.

--

TMW, you start to make too many wrong turns.

Bruno

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...

"james bejon" wrote in message <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...


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.

On Thursday, October 11, 2012 10:14:08 AM UTC+13, Richard Crozier wrote:
> "james bejon" wrote in message <k54nd8$mcf$1@newscl01ah.mathworks.com>...
>
> 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.

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...

--

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...

--

dpb <none@non.net> wrote in message <k56jgt$sn2$1@speranza.aioe.org>...
>
> > 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?

>
> 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.

On 10/11/2012 9:54 AM, Matt J wrote:
> dpb <none@non.net> wrote in message <k56jgt$sn2$1@speranza.aioe.org>...
...

>> 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).

--

dpb <none@non.net> wrote in message <k56vro$ugk$1@speranza.aioe.org>...
>
> > 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.

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" <r.crozier@ed.ac.uk> 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.

"james bejon" <jamesbejon@yahoo.co.uk> 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.
 

"Penny Anderson" <penny@mathworks.com> wrote in message <k59r7r$2v9$1@newscl01ah.mathworks.com>...
>
> 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?

> 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?

On 10/12/2012 2:32 PM, Penny Anderson wrote:
> "james bejon" <jamesbejon@yahoo.co.uk> 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.

--

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.

--

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.

--

"Penny Anderson" <penny@mathworks.com> wrote in message <k59qn5$p3$1@newscl01ah.mathworks.com>...
> 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

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" <none@non.net> wrote in message news:k5a0mu$2em$1@speranza.aioe.org...
> On 10/12/2012 2:32 PM, Penny Anderson wrote:
>> "james bejon" <jamesbejon@yahoo.co.uk> 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.

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.

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" <none@non.net> 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.

--

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.

--

dpb <none@non.net> wrote in message <k5afng$139$1@speranza.aioe.org>...
> 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

"Bruno Luong" <b.luong@fogale.findmycountry> wrote in message <k5b5ds$moj$1@newscl01ah.mathworks.com>...
> dpb <none@non.net> wrote in message <k5afng$139$1@speranza.aioe.org>...
> > 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.

"Penny Anderson" <penny@mathworks.com> wrote in message <k59qn5$p3$1@newscl01ah.mathworks.com>...
> 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.
>

Penny, thank you for commenting on behalf of TMW, and I am glad TMW have decided not to reduce the functionality of interp1. I appreciate TMW responding to customer concerns.

It is difficult for me to say what implications the loss of the other functionality in interp1 might have for me, as I've only just discovered the change is being considered. I am quite busy at work just now and back testing 7 years worth of code to see what effect the loss of the functionality might have, perhaps in places I've forgotten I even used it, is not something I have time to do just now.

Now, a cynical person might guess that you ask what I'm using interp1 for because in your customer interaction training it was something you were told to do (ask such questions to appear to be engaging with the customer, and make them feel part of the decision process, just as questions are asked at the end of blogs and whatnot for similar reasons). But since you asked, in this most recent case I have sampled the x and y components of a magnetic field and wish to interpolate new points for both components at the same locations along a line.

I honestly cannot think of a reason to remove such functionality from an existing function which has been around and stable for years. The maintenance requirements must be zero. I also do not understand what descision process could lead to this conclusion? I mean, maybe you decide to remove interp1 altogether and replace it, I could understand. I would be equally unhappy, but it might make some kind of sense, but actually spending dev time removing functionality? Bizarre. Again, who approves a budget for such a strange decision?

If you want to replace interp1, here are some suggestions. Sort out the Matlab namespace issues by actually properly implementing namespaces (I gather there are some issues with the pakage folders method you've introduced, or else you'd be using them al lot more on your own code), and move deprecated function to another namespace e.g.

legacy.interp1
r2012a.interp1

or something. This way it can be fixed in most of my code with a simple string find and replace. Even better, for really lazy/busy customers introduce automatic tools to do this for them. Perhaps something like the profiler, but for code change issues. Of course this would also break all my code on older releases, so I would still be annoyed as it would force upgrading every Matlab client I expected to run the code on, but it would at least seem logical to me.

Alternatively, you could deprecate and release the code on the FEX explaining no maintenance will be done. There could be a whole bundle of deprecated functions with all the original help docs etc.

What you should not do is just push potentially hours of code checking work onto me.

S. Lord (not speaking for TMW) elsewhere on this thread points out that the functionality is listed as 'Still Runs' and implies it is therefore not a problem, and that this is the best way to ask users about possible changes. I consider this a strange way of asking about such things. In what other situation is telling someone that something is going to change, then changing your mind about it when everyone reacts in horror, the same as asking in advance? I also do not have time to pore over the release notes of releases to see the impact it will have on me. This implies I have to read the release notes in detail and then try and remember if I've used any of the functionality in my back catalog of code. I might not even have written some of it myself, it might be taken from a colleage or the FEX. Also, I might not even know when my department, who makes these decisions, will decide to
upgrade, if ever!

So again, thanks for listening to my, and others, concerns, I am glad you are listening. I would appreciate even more though that you change internally your decision process on these things.

"Matt J" wrote in message <k5bgnk$s96$1@newscl01ah.mathworks.com>...
> 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

"Bruno Luong" <b.luong@fogale.findmycountry> wrote in message <k5bm0c$fgs$1@newscl01ah.mathworks.com>...
> "Matt J" wrote in message <k5bgnk$s96$1@newscl01ah.mathworks.com>...
> > 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.

"Matt J" wrote in message <k5bogv$nch$1@newscl01ah.mathworks.com>...

>
> 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

"Bruno Luong" <b.luong@fogale.findmycountry> wrote in message
news:k5bpkl$qvc$1@newscl01ah.mathworks.com...
> "Matt J" wrote in message <k5bogv$nch$1@newscl01ah.mathworks.com>...
>
>>
>> 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

"dpb" <none@non.net> 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

"Steven_Lord" <slord@mathworks.com> wrote in message <k5hae9$am2$1@newscl01ah.mathworks.com>...

>
> 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.

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/

"Richard Crozier" <r.crozier@ed.ac.uk> wrote in message
news:k5hbsc$gbs$1@newscl01ah.mathworks.com...
> "Steven_Lord" <slord@mathworks.com> wrote in message
> <k5hae9$am2$1@newscl01ah.mathworks.com>...
>
>>
>> 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

On 10/15/2012 10:34 AM, Steven_Lord wrote:
> "dpb" <none@non.net> 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.

--

"Steven_Lord" <slord@mathworks.com> wrote in message <k5hfec$s8$1@newscl01ah.mathworks.com>...
>
>
> "Richard Crozier" <r.crozier@ed.ac.uk> wrote in message
> news:k5hbsc$gbs$1@newscl01ah.mathworks.com...
> > "Steven_Lord" <slord@mathworks.com> wrote in message
> > <k5hae9$am2$1@newscl01ah.mathworks.com>...
> >
> >>
> >> 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.

On 10/15/2012 12:45 PM, dpb wrote:
> On 10/15/2012 10:34 AM, Steven_Lord wrote:
>> "dpb" <none@non.net> 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.

--

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/

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

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".

--

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

--

"Bruno Luong" <b.luong@fogale.findmycountry> wrote in message <k5hql2$ftm$1@newscl01ah.mathworks.com>...
> 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

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.

--

dpb <none@non.net> wrote in message <k5ij5o$a82$1@speranza.aioe.org>...
>
> 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

On 10/16/2012 2:21 AM, Bruno Luong wrote:
> dpb <none@non.net> wrote in message <k5ij5o$a82$1@speranza.aioe.org>...
>>
>> 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.

--

> 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.

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. :(

--

dpb <none@non.net> wrote in message <k5jtao$eh5$1@speranza.aioe.org>...
>
> 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

On 10/16/2012 1:59 PM, Bruno Luong wrote:
> dpb <none@non.net> wrote in message <k5jtao$eh5$1@speranza.aioe.org>...
>>
>> 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.

--

dpb <none@non.net> wrote in message <k5kdh2$qj3$1@speranza.aioe.org>...
> On 10/16/2012 1:59 PM, Bruno Luong wrote:
> > dpb <none@non.net> wrote in message <k5jtao$eh5$1@speranza.aioe.org>...
> >>
> >> 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).

On 10/16/2012 3:09 PM, Richard Crozier wrote:
> dpb <none@non.net> wrote in message <k5kdh2$qj3$1@speranza.aioe.org>...
...

>> 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.

--