[Octave-bug-tracker] [bug #65553] stream2 doesn't extend matrices like matlab

[Hg200]

Follow-up Comment #2, bug #65553 (group octave):

Thank you for the report. Two issues are addressed here. First topic is to
specify the input data x, y as vectors instead of 2D mesh grids. It looks like
Matlab has an undocumented feature here. The documentation says that x, y must
be a 2D array with the same size as u, v. However, I like the idea of being
able to specify x,y also as a vectors. The second issue is how to deal with
reversed input data. The Matlab documentation only says "monotonic", but I
haven't found anything about "ascending" or "descending". And it looks like
Matlab also accepts reversed input data.

1.) If we add the "vector input" feature to Octave, we also need to add it in
the stream3() function. Let's take the example from the Octave demo. The
following stream3() code runs in Matlab, but not in Octave:

[x, y, z] = meshgrid (-1:0.4:1, -2:0.2:2, -3:0.3:0);
u = - 0.08 * x - y; v = x - 0.08 * y; w = - 0.04 * ones (size (x));
streamline (x(1, :, 1), y(:, 1, 1), squeeze (z(1, 1, :)), u, v, w, 1, 0, 0);
view (3); axis equal tight;


2.) I have doubts about the "doflip" proposal made in the original submission.
If the input vector is reversed due to descending order, the code also
reverses the vector field data. Matlab does not seem to do this. With the
patch from the original submission, the following example results in different
plot outputs between Octave and Matlab. The Matlab representation is correct,
but Octave is wrong:

[x, y] = meshgrid (-5:5, -4:4);
x = -x;
u = x - 2 * y; v = 2 * x - 3 * y;
sx = [3, 0, -1, -2, -3, 0, 1, 2]; sy = [3, 3, 3, 3, -3, -3, -3, -3];
streamline (x(1,:), y(:,1), u, v, sx, sy, 0.05);
hold on;
quiver (x, y, u, v);
scatter (sx(:), sy(:), 20, "filled", "o", "markerfacecolor", "r");
grid on; axis equal;


I feel it is necessary to elaborate the dependencies in more detail. It is a
long time ago, but if i remember correctly the Runge-Kutta integrator in
stream-euler.cc should conceptually also be able to deal with descending input
data. But i have to check this in detail.

Although both topics are linked in some way, my proposal is to split this
report:
--> Feature request "x,y vector input instead of matrix input"
--> Compatibility with descending input data



    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65553>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/