I have been trying to solve this issue with out any luck so far.
From the Coursera course "Introduction to Data, Signal, and Image Analysis with MATLAB" the below code is retrieved. I'm trying to see if I can get this working in Octave 9.2. But that result in the error:
error: contourc: X, Y, and Z must be real numeric matrices error: called from contourc at line 110 column 5 contour at line 146 column 14 contour at line 80 column 18 classification1 at line 19 column 3
The class of X, Y and cls is double and the size of all 3 is 4x8.
Reading this post: Octave Contour plots The contour function works fine. No error. But with the code:
function classification1()
load fisheriris
pkg load statistics
[~,~,s] = unique(species);
figure(1);
plot(meas(s==1 ,1), meas(s==1, 2), 'rx')
hold on
plot(meas(s==2 ,1), meas(s==2, 2), 'go')
plot(meas(s==3 ,1), meas(s==3, 2), 'b*')
xlabel('Feature 1');
ylabel('Feature 2');
legend('setosa', 'versicolor', 'virginica');
[X,Y] = meshgrid(4:.01:8, 2:.01:4.5);
cls = my_iris_classifier([X(:), Y(:)]);
cls = reshape(cls, size(X));
contour(X, Y, cls==1,[1,1], 'r--');
contour(X, Y, cls==2, [1, 1], 'g--');
contour(X, Y, cls==3, [1, 1], 'b--');
endfunction
function class = my_iris_classifier(feat)
class = zeros(size(feat,1),1);
for i = 1:size(feat,1);
if feat(i,1) > 6
class(i) = 3;
elseif feat(i,2) > 3
class(i) = 1;
else
class(i) = 2;
endif
endfor
endfunction
it doesn't.
It's undocumented for Matlab to permit a logical input for the Z data in contour. See the matlab help for contour and contourc. Octave wrote its contourc to do input checking and throw an error for an incorrect input type, and that's what you're seeing. As an octave developer mentioned in your crosspost over at the Octave help forum, the best immediate path forward would be to recast all of the logical inputs coming from statements like cls==1
as type double
, for example:
contour(X, Y, double(cls==1),[1,1], 'r--');
This was previously captured in Octave bug #64078 which identified a long list of plot objects that limit or improperly handle certain input types. Not all of them are necessarily expected to be expanded, as Octave is generally hesitant to adopt undocumented behavior as that can (and has in the past) changed without notice causing further grief years down the road, but it can be considered on a case-by-case basis but at a minimum the known non-support of Matlab-undocumented behavior could be documented in Octave. This sort of compatibility seems fairly trivial, though, so it may improve in the future.