I changed the input validation to be tighter and updated the BIST tests in this changeset: https://hg.savannah.gnu.org/hgweb/octave/rev/d8e5e55c3cf5.

Marking as Fixed and closing report.

most colormaps, (e.g., viridis(), jet(), etc) take a single numeric input for the number of colors/rows to return. This is specified in the docs as a scalar input.  matlab colormap docs specify that it must be a nonnegative, scalar integer.

Checking the input handling, there is inconsistency between color maps, with only isscalar being checked and the output highly dependent on whether the map is generated from an algorithm, interpolated, etc.

I haven't checked all of the maps listed in 'help colormap', but a few examples:

viridis:

>> viridis (5)
ans =

   2.6700e-01   4.8743e-03   3.2942e-01
   2.3022e-01   3.2130e-01   5.4549e-01
   1.2815e-01   5.6511e-01   5.5089e-01
   3.6286e-01   7.8670e-01   3.8659e-01
   9.9325e-01   9.0616e-01   1.4394e-01

>> viridis (5.1)
ans =

   2.6700e-01   4.8743e-03   3.2942e-01
   2.3022e-01   3.2130e-01   5.4549e-01
   1.2815e-01   5.6511e-01   5.5089e-01
   3.6286e-01   7.8670e-01   3.8659e-01
   9.9325e-01   9.0616e-01   1.4394e-01

>> viridis ([5 4])
error: viridis: N must be a scalar
error: called from
    viridis at line 45 column 7
>> viridis (5+i)
ans =

   2.6700e-01   4.8743e-03   3.2942e-01
   2.3022e-01   3.2130e-01   5.4549e-01
   1.2815e-01   5.6511e-01   5.5089e-01
   3.6286e-01   7.8670e-01   3.8659e-01
   9.9325e-01   9.0616e-01   1.4394e-01

>> viridis(-5)
ans = [](0x3)

spring:

>> spring(5)
ans =

   1.0000        0   1.0000
   1.0000   0.2500   0.7500
   1.0000   0.5000   0.5000
   1.0000   0.7500   0.2500
   1.0000   1.0000        0

>> spring(5.1)
error: conversion of 5.1 to int64_t value failed
error: called from
    spring at line 55 column 7
>> spring([5 4])
error: spring: N must be a scalar
error: called from
    spring at line 40 column 7
>> spring(5+i)
warning: imaginary part of complex colon arguments is ignored
warning: called from
    spring at line 56 column 7

ans =

   1.0000 +      0i        0 +      0i   1.0000 -      0i
   1.0000 +      0i   0.2353 - 0.0588i   0.7647 + 0.0588i
   1.0000 +      0i   0.4706 - 0.1176i   0.5294 + 0.1176i
   1.0000 +      0i   0.7059 - 0.1765i   0.2941 + 0.1765i
   1.0000 +      0i   0.9412 - 0.2353i   0.0588 + 0.2353i

>> spring(-5)
ans = [](0x3)

jet:

>> jet(5)
ans =

        0   0.5000   1.0000
        0   1.0000   1.0000
   0.5000   1.0000   0.5000
   1.0000   1.0000        0
   1.0000   0.5000        0

>> jet(5.1)
error: conversion of 5.1 to int64_t value failed
error: called from
    jet at line 71 column 7
>> jet([5 4])
error: jet: N must be a scalar
error: called from
    jet at line 46 column 7
>> jet(5+i)
error: mod: not defined for complex numbers
error: called from
    jet at line 65 column 20
>> jet(-5)
ans = [](0x3)

(this report follows on patch #10064 proposed for the Spring colormap, but it would make sense to apply any changes to all maps consistently.)

Unless there's a rational use case for allowing non-positive integer valued inputs, I'd recommend adding input checks to catch and provide consistent error messages for other inputs.