bugGNU Octave - Bugs: bug #48272, unable to set a colormap named...

 
 

bug #48272: unable to set a colormap named list by name

Submitted by:  Carnë Draug <carandraug>
Submitted on:  Mon 20 Jun 2016 03:09:02 AM UTC  
 
Category: Octave FunctionSeverity: 3 - Normal
Priority: 5 - NormalItem Group: None
Status: FixedAssigned to: Carnë Draug <carandraug>
Originator Name: Open/Closed: Closed
Release: devOperating System: Any

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Sun 26 Jun 2016 12:37:25 PM UTC, comment #13:

@Carne,

In hindsight ... should the registration process be reinstated and "__list__" be used in order to obtain a list of registered colormaps?

Ben Abbott <bpabbott>
Project Member
Sun 26 Jun 2016 12:22:06 PM UTC, comment #12:

Sorry about that. I believe it's fixed now

http://hg.savannah.gnu.org/hgweb/octave/rev/19cfad4e4112

Carnë Draug <carandraug>
Project MemberIn charge of this item.
Sat 25 Jun 2016 02:19:11 PM UTC, comment #11:

Also, make check gives

Lachlan Andrew <lachlan>
Project Member
Sat 25 Jun 2016 01:18:35 PM UTC, comment #10:

Carnë, I now get

when I start Octave. I deleted the PKG_ADD file, but it seems to be regenerated by make, and contains a colourmap registration.

Could you fix that? Thanks :)

Lachlan Andrew <lachlan>
Project Member
Sat 25 Jun 2016 10:07:42 AM UTC, comment #9:

@Carnë:
Got distracted, sorry.

Looking into your final Q in comment #3 (real use case):
Yes I can come up with one, but in the end it turns out that registering etc. is nice but not really required.

Anyway I'm OK with you having removed it.

Philip Nienhuis <philipnienhuis>
Project Member
Fri 24 Jun 2016 09:52:47 PM UTC, comment #8:

Pushed http://hg.savannah.gnu.org/hgweb/octave/rev/894239974868

Carnë Draug <carandraug>
Project MemberIn charge of this item.
Tue 21 Jun 2016 08:48:04 PM UTC, comment #7:

> What about adding a new function ("colormap_list"?), that will print all available colormaps?


No. That would allow to have a colormap named list but it doesn't address the other issues with this functionality that make it unreliable. Also, if this feature wasn't useful until now, any new function to do the same thing will go just as unused, and we have enough code to maintain as it is.

Do you have a real current case that could be simplified with this functionality?

Carnë Draug <carandraug>
Project MemberIn charge of this item.
Tue 21 Jun 2016 08:37:31 PM UTC, comment #6:

Lachlan: if the (un)register options will be removed,
there will be only core colormaps.
BTW the persistent cell cmap_list contains all colormaps (see colormap.m)

Avinoam Kalma <avinoam>
Project Member
Tue 21 Jun 2016 07:33:07 AM UTC, comment #5:

I like the idea of reducing feature clutter.

The fastest, least memory hungry, and easiest to maintain lines of code are the ones that aren't there.

Avinoam, it would be simple to have a .m function that lists all of the core colourmaps. Would that suffice? (It would for me.) Otherwise, all of the machinery of registering would still be required.

Lachlan Andrew <lachlan>
Project Member
Tue 21 Jun 2016 05:03:15 AM UTC, comment #4:

What about adding a new function ("colormap_list"?), that will print all available colormaps?

Avinoam Kalma <avinoam>
Project Member
Mon 20 Jun 2016 04:44:12 PM UTC, comment #3:

> Is your plan to remove all of the extensions (incl. (un)register), or just the "list" option?


All. Because there's no point in registering if there's no use for the registry.

> In principle the "list" option is fairly useful on its own as it is an easy way to find out available colormaps. Does the manual contain an overview like e.g. in the on-line Matlab docs? I suppose there is.
> (I don't know the manual by heart, I just googled through the on-line manual but haven't found an overview there).


In principle is it useful, but in practice is unused. And yes, there's a section in the manual that includes a list of all colormaps. If you run "doc colormap", it is followed by rgbplot (a function that maps a colormap), and then by all the core colormaps.

> Speaking for myself, limitations are rarely a problem as long as they're properly documented and don't provoke crashes or errors.


An example of an error is what happens with a colormap named list.

> GIS raster files read with the mapping package can have colormaps ("anonymous" ones until they are, well, "registered" as you call it); so I can imagine the register / list features could be helpful when doing much work with such files.


Do you have a real use case now where this is useful?

Carnë Draug <carandraug>
Project MemberIn charge of this item.
Mon 20 Jun 2016 03:44:41 PM UTC, comment #2:

Is your plan to remove all of the extensions (incl. (un)register), or just the "list" option?

In principle the "list" option is fairly useful on its own as it is an easy way to find out available colormaps. Does the manual contain an overview like e.g. in the on-line Matlab docs? I suppose there is.
(I don't know the manual by heart, I just googled through the on-line manual but haven't found an overview there).

Speaking for myself, limitations are rarely a problem as long as they're properly documented and don't provoke crashes or errors.

GIS raster files read with the mapping package can have colormaps ("anonymous" ones until they are, well, "registered" as you call it); so I can imagine the register / list features could be helpful when doing much work with such files.

Philip Nienhuis <philipnienhuis>
Project Member
Mon 20 Jun 2016 10:49:07 AM UTC, comment #1:

Here's the rest of the bug report because of problems with markdown

Some years ago, I thought it would be nice to have a way to retrieve a list of
available colormaps programatically. For that, I added the option "list" to
colormap().

The bad result of it is that a colormap named list cannot exist (well, it
can't be set by name via colormap). I know colormap() already has the
limitation of a colormap named default (and we can't change that for Matlab
compatibility) but that's not a good example to follow.

So I'm proposing removing it.

I'm not sure that this feature is useful. I never heard of anyone making use
of it. Even if it is used, it only lists colormaps that are registered, and
again, I've never heard of anyone registering colormaps since that's also an
Octave only feature. In addition, the list may return missing colormaps since
it's possible that a user shadowed a colormap since it was registered.

So unless anyone thinks this is a useful feature, I will remove it. It also
means less initialization code since Octave won't have to register all of its
core colormaps anymore (not that this would have any significant impact on
time).

Carnë Draug <carandraug>
Project MemberIn charge of this item.
Mon 20 Jun 2016 03:09:02 AM UTC, original submission:

The colormap function will not accept a colormap named list because it conflicts with the "list" option.

Carnë Draug <carandraug>
Project MemberIn charge of this item.

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Digest:
   bug dependencies.

 

Carbon-Copy List
  • -unavailable- added by bpabbott (Posted a comment)
  • -unavailable- added by rik5 (Updated the item)
  • -unavailable- added by lachlan (Posted a comment)
  • -unavailable- added by avinoam (Posted a comment)
  • -unavailable- added by carandraug (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 10 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sun 26 Jun 2016 12:22:06 PM UTCcarandraugStatusIn Progress=>Fixed
      Open/ClosedOpen=>Closed
    Sun 26 Jun 2016 10:34:37 AM UTClachlanDependencies-=>bugs #48311 is dependent
    Sat 25 Jun 2016 02:19:11 PM UTClachlanStatusFixed=>In Progress
    Sat 25 Jun 2016 01:18:35 PM UTClachlanOpen/ClosedClosed=>Open
    Fri 24 Jun 2016 09:52:47 PM UTCcarandraugStatusIn Progress=>Fixed
      Open/ClosedOpen=>Closed
    Fri 24 Jun 2016 03:27:06 PM UTCrik5CategoryNone=>Octave Function
      StatusNone=>In Progress
      Assigned toNone=>carandraug

    Back to the top


    Powered by Savane 3.1-cleanup1