[Octave-bug-tracker] [bug #65011] improve input handling for colormaps

[Nicholas Jankowski]

URL:
  <https://savannah.gnu.org/bugs/?65011>

                 Summary: improve input handling for colormaps
                   Group: GNU Octave
               Submitter: nrjank
               Submitted: Mon 11 Dec 2023 11:04:22 AM EST
                Category: Octave Function
                Severity: 2 - Minor
                Priority: 5 - Normal
              Item Group: Unexpected Error or Warning
                  Status: Confirmed
             Assigned to: None
         Originator Name: 
        Originator Email: 
             Open/Closed: Open
                 Release: dev
         Discussion Lock: Any
        Operating System: Any
           Fixed Release: None
         Planned Release: None


    _______________________________________________________

Follow-up Comments:


-------------------------------------------------------
Date: Mon 11 Dec 2023 11:04:22 AM EST By: Nicholas Jankowski <nrjank>
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.







    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65011>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/