Question about hist behavior for processing char inputs

Bug report about behavior of `hist` here: GNU Octave - Bugs: bug #60482, hist() misses error for... [Savannah]

The bug report is about what happens when a char array is passed as the second variable. See below where the user was trying to use ‘hist’ for letter frequency

``````>> data = 'AABBBBBCCCCCCDDDDDDEFFFFFGGGHHHHHHHJJJJJJKKLLLLMMMMMMMMNNOOOPPPPPPPRRRSSSSSSSSTTUVVVWWWWWWWW';

>> u = unique(data)
u = ABCDEFGHJKLMNOPRSTUVW

>> freq = hist (data, u)
error: isfinite: argument must be numeric
error: called from
hist at line 99 column 11

octave:34> freq = hist (data+0, u)
freq =

13    7    8    7   12   10   10    3   10   12

octave:36> freq = hist (data+0, u+0)
freq =

2   5   6   6   1   5   3   7   6   2   4   8   2   3   7   3   8   2   1   3   8
``````

Matlab errors on both the hist(data,u) and hist(data+0, u) inputs. Octave, however, assumes any char input after the first is meant to be passed to the plotting function and allows it. (matlab doesn’t pass any options to hist plot functions, and just ignores trailing char inputs). seeing char’s in the bin input, Octave assumes it’s a property, and reverts to the default 10 bins and calculates an output.

Should Octave’s hist issue an error here? user suggested something like “if(nargout>0) error if first inputs are non-numeric”. if you are plotting, you’ll get a ‘bad property’ error if it’s invalid. instead of erroring, should it instead do a conversion to double and produce the correct result?

do we guess a correction for the user, notify the user of a problem, or allow things to continue as is?

I think we can strike the last option. We can clearly do better than the status quo, so we should.

the simplest would probably be to do what was suggested by the user. if (nargout), throw an error if the first two includes a char input. that would more or less match Matlab behavior, so wouldn’t introduce a cross-compatibility concern. I guess it could create a backward compatibility concern if there’s a reason we need to allow text there. if plotting, any text there that isn’t a valid property will throw an error.

Also it seems odd, but both matlab and octave allow you to have a handle in first position even if you opt for an output. both create an empty default axes object and ignore any trailing char inputs, then produce the numerical output. so in that case, 3rd position throws the error.