interp1 - rant

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

Answer 1

[Walter Roberson]

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.

Answer 2

[David J. Mack]

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

Answer 3

[Sean de Wolski]

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?

Answer 4

[Hook]

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
mask; % logical mask of the same size as 'data' with nnz(mask) = N
result = data(mask));

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.

[Adam]

1x1xN

is not a vector in Matlab so I wouldn't expect it to behave as one. I expect anything for which

isvector

returns true to act as a vector and anything for which it doesn't not to.

I'd prefer it if vectors were 1d and not always considered 2d, but I can see why they are so I just live with it. If I didn't want to I'd just use other software. Maybe isvector should be defined in such a way that a 15-dimensional input with 14 singleton dimensions is also considered a vector, but I imagine that itself would lead to a whole load of inconsistencies in different areas too.

There are weird inconsistencies and things that don't feel intuitive in every language, but then what is intuitive to one person isn't intuitive to another.

[Stephen23]

"I'd prefer it if vectors were 1d and not always considered 2d"

Do you have a programming background?

The idea that vectors are 1D only seems to make sense for programmers. It has nothing to do with maths: a column vector is a totally different thing to a row vector. Algebra would make no sense with 1D vectors.

Of course we all ignore the infinite trailing dimensions that every array has... pity us poor humans who cannot manage them all.

[Adam]

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]

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.