matrixoctaveoctave-gui

The movstd function swaps output matrix dimensions?

I've noticed that the movstd function swaps the dimensions of my matrix.

My input is Mdata_rs a 3x5x100 matrix and the output movSTDdata_rs is a 5x100x3 matrix. I tested with a smaller 3D matrices (2x3x5) and it works fine. Did I miss something in the documentation?

Here is my code :

clear; close all; clc;

xlist = 1:5;
ylist = (1:3)*10;

% Making a LUT from x and y : LUT --> nConf | x | y
count = 1;
for kx=1:length(xlist)
 for ky=1:length(ylist)
   LUT(count,:) = [count xlist(kx) ylist(ky)];
   count = count+1;
   end
end

% Making the data --> nConf | measurement
% data :  1 x1
%         2 x2
%        ...
%        15 x15
%         1 x16
%         2 x17
%        ...
Nrounds = 100;
data = zeros(Nrounds*length(LUT),2); % Let's have a multiple rounds/cycles measurements
data(:,2) = rand(length(data),1); % Random measurements
data(1:floor(Nrounds)*length(LUT),1) = repmat(LUT(:,1),[floor(Nrounds) 1]); % Fill the nConf column

% Parameter to compute a noise approximation
wlen = 3; % window length
opt = 0; %see movstd doc

%% Reshaping the data in a 3D matrix with each column in the third axis is a conf with Nrounds layers
Mdata_rs = reshape(data(:,2),[length(ylist) length(xlist) Nrounds]);
movSTDdata_rs = movstd(Mdata_rs,wlen,opt,3);
output1 = median(movSTDdata_rs,3); %Get a noise approximation ignoring the possible base line

I've run it with matlab and there is no issue. I know I can go around it by using reshape() to get the right order but I would like to know why or at least when this behaviour appears.

Solution

  • It appears that there is a bug in movefun (called by movstd, movmean, etc.) in Octave 9.2.0. The function reshapes/permutes the input to flatten it to 2D and put the operating dimension into columns for simpler coding of the windowing operations. The function ends by restoring the shape, first by unflattening it with reshape, then by reversing the dim permutation. Unfortunately, it appears that the code should have used ipermute, not permute, and this issue only appeared when operating on dim > 2, and there were no self tests for nD data to catch that issue.

    A bug report has been opened at https://savannah.gnu.org/bugs/index.php?65927

    That will hopefully be fixed before version 9.3.0. In the meantime, it appears that correct functionality can be restored to your code by changing line 297 from:

    y = permute (y, [dperm, nd+1]);

    to

    y = ipermute (y, [dperm, nd+1]);

    UPDATE: A patch has been submitted to fix this bug. It should be available as part of Octave 9.3.0. If the fix is needed in the meantime, the 1-character fix above can be made to the movfun.m file in v9.2.0 (typing edit movfun within Octave).