interp1 - rant
1 Ansicht (letzte 30 Tage)
Ältere Kommentare anzeigen
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
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
Weitere Antworten (3)
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
Hook
am 12 Jan. 2017
4 Kommentare
Adam
am 12 Jan. 2017
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.
Siehe auch
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!