# interp1 - rant

10 Ansichten (letzte 30 Tage)
Hook am 12 Jan. 2017
Kommentiert: Walter Roberson am 12 Jan. 2017
Why on Earth does interp1 work with 1D vectors od size Nx1, 1xN but not 1x1xN? Why can't you (I am talking to you, MathWorks) simply do your job and stop trying to be smarter than everybody else? Thanks to this nice feature, my code is a real marvel to look at:
If world were perfect:
y = interp1(x(pos), y(pos), x);
Now:
shape = size(y);
y = reshape(interp1(reshape(x(pos), [], 1), reshape(y(pos), []), reshape(x, [], 1)), shape);
##### 0 Kommentare-2 ältere Kommentare anzeigen-2 ältere Kommentare ausblenden

Melden Sie sich an, um zu kommentieren.

### Akzeptierte Antwort

Walter Roberson am 12 Jan. 2017
V = @(x) x(:);
y = interp1(V(x(pos)), V(y(pos)), x);
The reshape on the probe locations and the outcome are not needed; the outcome will be the same shape as the probe locations.
##### 0 Kommentare-2 ältere Kommentare anzeigen-2 ältere Kommentare ausblenden

Melden Sie sich an, um zu kommentieren.

### Weitere Antworten (3)

David J. Mack am 12 Jan. 2017
If its only about the 1x1xN array not working, simply use squeeze. E.g.
x1 = squeeze(x); %x is 1x1xN, x1 is 1xN
Greetings, David
##### 0 Kommentare-2 ältere Kommentare anzeigen-2 ältere Kommentare ausblenden

Melden Sie sich an, um zu kommentieren.

Sean de Wolski am 12 Jan. 2017
Bearbeitet: Sean de Wolski am 12 Jan. 2017
You could use squeeze() to replace the inner reshapes:
y = reshape(interp1(squeeze(x(pos)), squeeze(y(pos)), squeeze(x)), size(y));
Of course, you could use griddedInterpolant directly and it's fine with it:
g = griddedInterpolant({x(pos)},y(pos));
g(x)
Why are you storing you array as a 1x1xp?
##### 0 Kommentare-2 ältere Kommentare anzeigen-2 ältere Kommentare ausblenden

Melden Sie sich an, um zu kommentieren.

Hook am 12 Jan. 2017
Guys, thank you for you answers, especially the one by Walter Roberson is truly helpful. I know you mean well but my 'question' wasn't really about solving this particular problem but rather complain about this extremely annoying "helpful" philosophy behind some of MATLAB's design decisions, which is supposed to somehow help the user, but actually makes things worse. Takes this case - interp1 is supposed to do 1D interpolation, I gave it 1D vectors so why does it care about their shape? Why is it trying to second-guess some "best practices" and force me to a certain scenario which the wise people at MathWorks foresaw as "the only sensible way"?
Sean de Wolski:
Why are you storing you array as a 1x1xN?
Forgive me, but this is exactly the line of thinging that's the culprit. I can image that out of the blue, it seems more "logical" to store 1D vectors as Nx1 but if it's not necessary for the task at hand, why do you care? (and by you I mean the guy who implemented interp1) I can tell you straightway, though. My data points (vectors) are parametrized by 2 parameters and stored in matrix (cube) 'data' which is indexed as data(param_1, param_2, :). Now I need to run interpolation on some of the data series and replace them in place in the 'data' array, so I need to preserve the 1x1xN shape.
Another example of MATLAB's effort to "help" which only causes problems.
data; % array of arbitrary shape
What is size(result)?? In almost all cases, the answer is [N 1]. But when data is row vector, then the size is [1 N]. Why is this not consistent?? I can tell you, because they tried to "help" us, thing that "ok, if there was a vector in the input, the user probably wants the same vector on the output, right?" Wrong. What the user actually wants is consistent behavior they can rely on. This way you have to reshape the result every time, just to be sure. So the "benefit" of the design decision is gone and because it's not something that is immediately obvious, it actually cost me some time to find and correct the error when, by pure chance, my code was run with 'data' of the particular special size.
And I could go on with these examples. So my plea to MATLAB designers is: Stop thinging what the user should do because it's what you would do in your toy scenario, stop thinging that you know better that your users and design MATLAB accordingly - in a consistent, logical manner. An important person (I guess) from MathWorks actually once told me (in an official capacity) face to face that MATLAB is often used by engineers who are not all that smart so it needs to be designed accordingly, in a foolproof easy to use way. Well, drop that. I am not an engineer so I have no horse in this race but those engineers are probably smarter than many of you and all they want is a consistently working and logicaly designed product. Leave the rest to them.
##### 4 Kommentare2 ältere Kommentare anzeigen2 ältere Kommentare ausblenden
Bearbeitet: Adam am 12 Jan. 2017
Well, yes, I guess my expectations on a vector do come from a C++ background originally and rows vs columns being different was the reason I can see why they are that way, but it still has an inconsistent feel about it when I visualise 1d as a line, 2d as a slice, 3d as a volume, that in Matlab 2d also encompasses something that is axis-aligned 1d in a 2d space.
It doesn't bother me most of the time, though I did write quick convenience functions named row( ) and column( ) to enforce one or the other in cases where it matters, but I can't be sure which I am getting or don't want to enforce it on input because where it came from it was just 1d and didn't matter whether it was row or column.
Since Matlab is essentially a language of matrices the distinction of row and column vectors obviously makes sense, but in probably > 75% of my usages of 1d data I am just using a 'vector' of data and don't care about orientation except for when I am forced to by dimension mis-matches! And I suppose those only come from me trying to use the efficient Matlab methods for operating on data rather than C++ for loop style.
Walter Roberson am 12 Jan. 2017
A lot of the time people do not care about the orientation of their vectors and it would be an undue burden to force them to care at every step. The requirements of "calculator" type operations (where people should not have to know or care) and of rapid prototyping (get something put together quickly even if it is not perfect) are that the convenience conversions be there. But then when it comes time for more serious programming, the convenience features can get in the way.
I have mused from time to time that there should be something like
feature('strictorientation')
to turn off the convenience reshaping. The idea being to set it once in your program and have it stay on. But I realized that there are all kinds of already written routines around that such a setting would break, and those need to be exempted without having to change them. So the best I have come up with so far is the idea that Mathworks could implement something like
%#pragma strictorientation
that was to affect only the one routine. Or perhaps it would extend to all nested routines defined in the same function. And perhaps if it occurred before the first function or classdef it would extend to the file.
I did not pursue the idea far enough to figure out whether it might sometimes be necessary to exempt individual anonymous functions from the scope.

Melden Sie sich an, um zu kommentieren.

### Kategorien

Mehr zu Orange finden Sie in Help Center und File Exchange

### Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!

Translated by