'soon', as always, is a highly relative measurement.

i stepped through all of the functions in /scripts/plot/draw, attempted to test simple cases with int and logical inputs, and then tested them against matlab 2023a.  it's quite a pile, and my notes are the most consistently laid out, but they are in the blocks below and attached as a text file. 

Split the functions into those that present a compatibility concern (i didn't check whether they were all documented or undocumented incompatibilities), or were just Octave inconsistencies/poor input checking/error messaging.  (any functions not mentioned here had no issues identified)

I guess these could be tackled here, but maybe they can be better tackled split out (or maybe intelligently grouped) into separate reports.

Matlab compatibility concerns:

FUNCTIONS/CALLS BELOW SHOULD WORK FOR MATLAB COMPATIBILITY:

bar(logical([1 0 1 0 1]))

area(logical([0 1]),logical([0 1]))

comet (logical ([0 1 0 1 0])
comet (logical ([0 1]), logical([0 1]))

compass: all should look the same, but in octave int32 loses arrowheads
and logical on 2nd input produces invalid linestyle error.
compass([0 1],[1 0])
compass(int32([0 1]),int32([1 0]))
compass(logical([0 1]),logical[1 0]))

contour: ints work ok but logicals should too. following should all be the same:
contour([0 1], [0 1], [0 0; 0 1])
contour(logical([0 1]), ([0 1]), ([0 0; 0 1]))
contour(([0 1]), logical([0 1]), [0 0; 0 1])
contour(([0 1]), [0 1], logical([0 0; 0 1]))

feather:
int32 removes arrowheads. logical errors on 2nd input. matlab fine with either
feather([0 1],[0 1])
feather(int32([0 1]),[0 1])
feather([0 1],int32([0 1]))
feather(logical([0 1]),[0 1]) #okay
feather([0 1],logical([0 1])) #'invalid linestyle' error

fill:
matlab ok with int or logical inputs.  octave changes xlim with int32.
error messages inconsistent with logical inputs

fill ([0 1 0], [0 0 1], 'r')  #ok, xlim = [-1 1]
fill (int32([0 1 0]), [0 0 1], 'r'), #same shape, but xlim = [0 1]
fill (int32([0 1 0]), int32([0 0 1]), 'r')  #same shape, but xlim = [0 1]
fill (([0 1 0]), int32([0 0 1]), 'r')#same shape, xlim = [-1 1]
fill (logical([0 1 0]), [0 0 1], 'r') #error: iargs(0): subscripts must be either integers 1 to (2^63)-1 or logicals
fill (([0 1 0]), logical([0 0 1]), 'r') # error: Invalid call to patch.  Correct usage is:...


mesh, meshc - ML ok with int's and logical. Octave ok with int,  strange error for x, y, z data logical
mesh(logical([0 1 0]),[4:6], logical([0 1 1;1 0 1;0 0 1]))
 __go_surface__: invalid value for array property "xdata"

meshz similar, but is ok with logical z.

waterfall same as mesh

pareto:
 group = {"A", "B", "C", "D"};
 count = [1 0 1 0];
octave okay:
 pareto(count, group)
 pareto(int32(count), group)
error in octave, same as type double in matlab (matlab int32 gives odd result):
 pareto(logical(count), group)

pie pie3- breaks with int. fine with logical
pie([0 1 1],[0 0 1]) - logicals ok. ints breaks rendering. ML ok with int, error on logical x


plot ok.  plot3 error on logical inputs: error: __go_line__: invalid value for array property.  ML accepts logicals

polar - polar([0 1 1], [1 0 1]) changes oddly if 2nd input is int.  logical ok. ML accepts both.

rectangle("Position", int32([0 0 1 1]), "Curvature", 1)
Position or curv as int makes curv=0.
logical pos draws ok but errors "error: invalid value for array property "position"".
logical curv no draw, "error: rectangle: curvature must be a 2-element vector or a scalar"
Matlab ok with int32. errors with logicals


ribbon([0 0; 1 1],[0 1; 0 1], 1)
int ok for x and y. plot changes for int width. (ML ok for x,y. odd error on width)
logical fine on width, odd error on x and y
 - if logical: "error: __go_surface__: invalid value for array property "ydata",..."
ML accepts all logical.

scatter - scatter ([0 0 1 1], [0 1 0 1])
ints ok.
logical for x or y produces "error: __go_scatter__: invalid value for array property"
scatter3 - same behavior, but logical is okay for x.
matlab accepts int or logical on all three


stairs ([1 0 1 0 1], [0 1 0 1 0]) is okay for int, both inputs break on logical.  ML works for logical on both inputs.


stem works for both int and logical, but xlimits change if X is int.  stem(int32([1 2 3 4]),([1 0 1 1])) vs  stem([1 2 3 4],([1 0 1 1])).  ML no change for either.


stem3 xlim and ylim change if they're int. stems can break if all3 are int.
logical z breaks rendering.
stem3([0 0 1 1], [0 1 0 1], [1 0 0 1])
ML okay with int or logical

Not Matlab compatibility concerns:

FUNCTIONS BELOW ARE INCONSISTENT IN OCTAVE OR COULD USE BETTER INPUT
VALIDATION/ERROR MESSAGING, BUT THEY ARE NOT SPECIFICALLY MATLAB COMPATIBILITY CONCERNS:

camlight:
figure(1); peaks; camlight(180,180)
figure(2); peaks; camlight(int32(180),180)
figure(3); peaks; camlight(180,int32(180))
figure(4); peaks; camlight(int32(180),int32(180))
2,3,4 differ from 1.  2 and 3 are the same as each other.
ML errors when any input is int.


cylinder:  matlab math error if R or n is int32. logical R ok. logical n errors
octave:
cylinder(1,10)
cylinder(logical(1),10) # looks good
cylinder(1, int32(10)) # looks good
cylinder(int32(1),10) # deforms into rectangular prism
cylinder(1, 1) # "0" width line from 0,1,0 to 0,1,1.  octave displays zoomed in to eps dimension
cylinder(logical(1), 1) - same
cylinder(1, int32(1)) - same
cylinder(1, logical(1)) - same
cylinder(int32(1), 1) - becomes 0 width.

ellipsoid:  matlab and octave fine for logical.
matlab math error (integers can only be combined with ...) for any int32
octave, int32 distorts that axis on any input
ellipsoid (0, 0, 0, 1, 1, 1)
ellipsoid (int32(0), 0, 0, 1, 1, 1)
ellipsoid (0, 0, 0, 1, 1, int32(1))
all look different

hist (if norm is an int, it messes up)
hist(Y), hist(Y,N), hist(Y,X) fine with int32, logical
hist(Y,X,Norm) breaks plot if Norm is int32, error if Norm is logical
ML - hist(Y), hist(Y,N), hist(Y,X) fine with logical Y,X, unless N=1. error if Y is int. ML doesnt' have a ...,Norm option

pcolor - ML and Octave fine with ints. ML errors on logical.  Octave is
fine with logcial C, but odd errors produced on x and y.


peaks - odd errors on n=1.  0 is just empty. matlab help says n must be integer>1.
 n>1 okay with int if x,y - int produces different output from double.  logical produces errors.
scalar N - int ok. (logical should fail n>1)
vector N - peaks([0 1]) different from peaks(int32([0 1])). odd error on logical. (matlab errors for int and logical)
(x,y) - peaks([0 1],[0 1]) changes shape for int inputs. '__go_surface__: invalid value for array property...' error for logical (ML errors for int and logical)

slice - breaks with logical input for x,y,z
slice([0 1],[0 1],[0 1],reshape([0,1,0,1,0,1,0,1],2,2,2), 1,1,0)
ints okay
logical produces errors. x: invalid call to interp3. y,z: "__go_surface__: invalid value for array property..."
v,sx,sy,sz okay.
Matlab errors for any values other than double or single.

stream2/stream3/streamline -
setting x,y,z to int will break the plot. ML disallows non float inputs.

streamribbon - int x y z gives error: xnorm: wrong type argument 'int32 matrix'. ML disallows non-floats.
Output is different from ML for demo1 scaled 10x even for floats.  (ribbon stops at 25 in ML).
[x, y, z] = meshgrid (0:2:40, -10:2:10, -10:2:10);
 u = - x + 100;
 v = 10 * z.*x;
 w = - 10 * y.*x;
 sx = [0, 0];
 sy = [0, 6];
 sz = [0, 0];
 streamribbon (x, y, z, u, v, w, sx, sy, sz);

same error with streamtube, but rendering is also terrible.

surf - ints fine. logical for x,y,z gives
error: __go_surface__: invalid value for array property "ydata", unable to create graphics handle
ML errors with logical inputs
same with surface, surfc, surfl

surfnorm - logical does same as surf.  ML does not allow int inputs.
[x,y,z]=peaks(10);
surfnorm(fix(x),fix(y),fix(z))
surfnorm(int32(fix(x)),fix(y),fix(10*z)) int32s on any input breaks the normal lines.


tetramesh - ok, with ints.  but Xs can't be logicals (patch invalid property error).  ML errors too.


trimesh and trisurf: ok with ints.  ok with logicals except for z.  Matlab behaves the same.
pts=[0 0 0; 0 0 1; 0 1 0; 1 0 0 ]
trimesh([1 3 2 4],pts(:,1),pts(:,2),pts(:,3)) #okay
trimesh([1 3 2 4],pts(:,1),pts(:,2),logical(pts(:,3))) #error: __go_patch__: invalid value for array property "facevertexcdata"

(file #55129)

Is there a list of other plotting functions that need to be checked for their behavior with logical or integer inputs?

patch pushed as noted in bug #59695.  all inputs can be any numeric type or logical.  this also applies to scale factor which can also now be 'off'.

https://hg.savannah.gnu.org/hgweb/octave/rev/ada96a467a28

Interesting. According to that report the data type is preserved. So the simple fix of recasting the inputs as double would fix the plot problem but wouldn’t be strictly compatible. Would instead have to change all of the operations using the data to double. (Or… cheat a bit and cast to double at the start and then recast the stored data to the input type at the end of the function)

i was looking at adding some input validation.  I can add a double conversion at the front end as well which should take care of this.

noticed that while

quiver(1,0)

produces a simple, horizontal single arrow quiver plot and

quiver(true, false)

produces an identical plot,

quiver(int32(1), int32(0))

does not. it produces an line going from 0,0 to 2,1, with no linesegment.

looking at the x and ydata, they stay as int32.  normally NaNs are used to separate data points, and int32 replaces them with 0s, and there arrowhead size calculations can't do fractions.

recommend the quiver/quiver3 functions internally convert data to double before handing of to `__quiver__`.