bugGNU Octave - Bugs: bug #39495, polar plot should have a circular...


bug #39495: polar plot should have a circular rho/theta axis

Submitted by:  Rik <rik5>
Submitted on:  Tue 16 Jul 2013 05:10:26 PM UTC  
Category:  Plotting Severity:  1 - Wish
Priority:  5 - Normal Item Group:  Feature Request
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  Closed
Release:  dev Operating 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)

Mon 06 Jul 2015 11:31:57 PM UTC, comment #27: 

Just for info: I included your
set (gca, 'rtick', [0:10:40])
in plotimages.m
and the plot for the Manual is now correct.

polar.m should still be fixed sometime, but the
Manual change can stay.

Michael Godfrey <godfrey>
Project Member
Fri 03 Jul 2015 05:02:11 PM UTC, comment #26: 

I see the problem.  This on the development branch with

parent: 20300:9de6949ec15f tip
graphics_toolkit.m: Fix typo in error message.

The command, in verbatim mode for the bug tracker, is

polar (0:0.1:10*pi, 0:0.1:10*pi);

The issue is that the rtick value is set to [0, 0.5, 1], but the range of the data is to ~31.  If I manually adjust the rticks it works.

set (gca, 'rtick', [0:10:40])

Rik <rik5>
Project Administrator
Thu 02 Jul 2015 10:59:32 PM UTC, comment #25: 

I get attached picture. Looks ok for me.

Thu 02 Jul 2015 03:39:14 PM UTC, comment #24: 

It appears that this patch has broken the polar plot
in the Manual.
polar (0:0.1:10*pi, 0:0.1:10*pi);
previously produced the plot in the Manual

Michael Godfrey <godfrey>
Project Member
Wed 02 Jul 2014 01:27:32 PM UTC, comment #23: 

Great, thanks Ben. So last patch works fine. For attached one I just added the commit message.

(file #31665)

Stefan Mahr <dac922>
Wed 02 Jul 2014 12:50:48 PM UTC, comment #22: 

Ive attached the result from Matlab for the commands below.

hold on

Ben Abbott <bpabbott>
Project Member
Wed 02 Jul 2014 12:08:11 PM UTC, comment #21: 

Ok, for plot->polar the axis rescales. What happens for polar->plot?

hold on

With attached diff, this example doesn't rescale.

(file #31660)

Stefan Mahr <dac922>
Wed 02 Jul 2014 01:31:56 AM UTC, comment #20: 

Thanks Ben.  That's what I expected.  'hold on' is usually interpreted to mean add the data only and don't change any other visual settings like axis ticks or colors.

Rik <rik5>
Project Administrator
Wed 02 Jul 2014 12:45:37 AM UTC, comment #19: 

I've attached the result from Matlab.

hold on

Ben Abbott <bpabbott>
Project Member
Tue 01 Jul 2014 10:32:10 PM UTC, comment #18: 

I added check for ishold.

I'm not sure what should happen with this code:

hold on

Should it keep the plot axis and grid or overwrite with polar scaling and grid? With attached patch it just overwrites the plot grid.

(file #31656)

Stefan Mahr <dac922>
Thu 26 Jun 2014 04:12:22 AM UTC, comment #17: 

I would be fine committing the last diff if you like.

I think we should probably address the FIXME note about not overriding existing axis preferences if ishold is on.  For example, when I use hold on and call polar several times I end up with several copies of the polar hggroup.  It would be better to just keep a single copy and adjust it as necessary.

Maybe test ishold and if it is on, look for an hggroup with the tag "polar_grid".  If it exists we can update it rather than create a new one.

Rik <rik5>
Project Administrator
Wed 25 Jun 2014 11:00:49 PM UTC, comment #16: 

Well, the easiest way is to use

  oldxlim = max (get (hax, "xlim"))/1.1;

But it looks soooo ugly. However, attached patch works so far...

(file #31620)

Stefan Mahr <dac922>
Wed 25 Jun 2014 10:52:14 PM UTC, comment #15: 

Nope, using rtick doesn't work, because it doesn't scale down after 'hold off'.

Stefan Mahr <dac922>
Wed 25 Jun 2014 10:26:15 PM UTC, comment #14: 

I removed 'lim = 1.1 * rtick(end);' because this leads to problems with 'hold on' plot: The axis get larger and larger with every plot.

hold on

A solution could be to replace the 'oldxlim' stuff with following lines:

    if (! isprop (hax, "rtick"))
      addproperty ("rtick", hax, "data");

    oldrtick = max (get (hax,'rtick'));
    if (! isempty (oldrtick))
      maxr = max (maxr, oldrtick);

Stefan Mahr <dac922>
Wed 25 Jun 2014 10:01:51 PM UTC, comment #13: 

The patch is almost there.  Changes I see

1) Re-instate

lim = 1.1 * rtick(end);

because the labels at 0 and 180 are not visible without this.

2) Use double quotes rather than single quotes.  For example, "xlim" rather than 'xlim' as this is the Octave coding convention.

3) For unused arguments use the ignored variable syntax of "~".  For example

function resetaxis (cax, d, ax, orig_props)
function resetaxis (~, ~, hax)

4) get (gca, 'xlim') is bound to return something.  I think you can remove the if test that has a comment on it.

if (! isempty (oldxlim))   ## can xlim be empty?

5) Use hax, instead of ax, in the resetaxis routine to mirror what is used at the start of the function with all of the addlistener calls.

6) Remove copy/paste comment

## FIXME: Probably don't want to delete everyone's listeners on colormap.

Rik <rik5>
Project Administrator
Wed 25 Jun 2014 09:37:16 PM UTC, comment #12: 

Attached a little copy&paste exercise from colorbar and basic 'hold on' support. Please comment.

(file #31619)

Stefan Mahr <dac922>
Wed 25 Jun 2014 07:32:00 PM UTC, comment #11: 

@Andreas: Unless there is a strong need, I'm comfortable using a hack to get the limits rather than creating a new C++ private function. polar() is a plotting routine which needs to run quickly only at human timescales of milliseconds; Performance is not critical.

@Stefan: The behavior of cla() changed for Matlab compatibility and that is why we are seeing the new errors with polar().  I think we need to follow the approach of legend() or colorbar() and delete the listeners when the axis is cleared.

Rik <rik5>
Project Administrator
Wed 25 Jun 2014 09:31:35 AM UTC, comment #10: 

The example with scalars doesn't trigger the bug. Most probably I tested with modified sources. Sorry.

However, the latest example still triggers the bug.

octave:1> close all
octave:2> polar([0 45 90],[1 1 1])
octave:3> polar([0 45 90],[2 2 2])
error: get: invalid handle (= -18.4632)
error: evaluating argument list element number 1
error: called from:
error:   /arb/devel/octave/octave-repos-hg/octave-hg/build-gcc/../scripts/plot/draw/polar.m at line 287, column 3
error:   /arb/devel/octave/octave-repos-hg/octave-hg/build-gcc/../scripts/plot/draw/polar.m at line 112, column 5

Stefan Mahr <dac922>
Wed 25 Jun 2014 09:03:59 AM UTC, comment #9: 

I've made some tests in ML R2014a.
If polar is called with only one input argument (or additional LineSpecs) theta = 1:length(rho). So

polar(2, 'o') is equal to polar(1, 2, 'o')
polar([2 4 5], '-o') is equal to polar(1:3, [2 4 5], '-o')

The complex input seems to be an octave addition and interferes with the ML behaviour.

Regarding Stefans bug report:
I think the my current rtick calculation is a little bit clumsy and I would like to have access to calc_ticks_and_lims from graphics.cc to directly calculate rtick and mtick from maxr without the "set xlim and get xtick hack".

Is this okay and what is the best way to archive this? My naive approach would be to create libinterp/dldfcn/__calc_ticks_and_lims__.cc as wrapper for axes::properties::calc_ticks_and_lims.

-- Andy

Andreas Weber <andy1978>
Project Member
Wed 25 Jun 2014 08:43:43 AM UTC, comment #8: 

Rik, this was just a minimal example. The bug occurs with following code too:

polar([0 45 90],[1 1 1])
polar([0 45 90],[2 2 2])

Stefan Mahr <dac922>
Tue 24 Jun 2014 11:42:37 PM UTC, comment #7: 

What does Matlab do for

polar (2)

I'm looking at the documentation

-- Function File:  polar (THETA, RHO)
-- Function File:  polar (THETA, RHO, FMT)
-- Function File:  polar (CPLX)
-- Function File:  polar (CPLX, FMT)
-- Function File:  polar (HAX, ...)

and I can't see that this form matches.  Maybe the input validation routines need to be improved so that an error is generated.

Rik <rik5>
Project Administrator
Mon 23 Jun 2014 06:51:26 PM UTC, comment #6: 

There are some problems with new polar plot. Following code produces an error:

close all

Also, the calculation of rtick fails, since xtick seems to depend xlim. Setting xlim was removed in previous changeset.

Attached a quick and dirty patch.

(file #31605)

Stefan Mahr <dac922>
Sun 11 May 2014 12:43:53 AM UTC, comment #5: 

I pushed the original changeset here (http://hg.savannah.gnu.org/hgweb/octave/rev/b5b73959907f).

I followed it with a second changeset that cleans things up and implements most of the other axes properties such as: color, layer, gridlinestyle, fontname, interpreter, etc.  That changeset is here (http://hg.savannah.gnu.org/hgweb/octave/rev/56bff71de2ca).

One open point is how to change the color of the polar grid lines and text labels.  Is this always black in Matlab?  For a rectangular plot you could do something like

set (gca, 'xcolor', 'r');

to change axis lines and labels.

We invented the rtick, stick properties.  Should we also invent rcolor and scolor to refer to these properties?

Rik <rik5>
Project Administrator
Mon 28 Apr 2014 09:56:04 PM UTC, comment #4: 

I ran a simple example using Matlab.

t = 0 : .01 : 2 * pi;
polar(t, sin(2 * t) .* cos(2 * t), '--r');
get (gca, 'xtick')
ans =   -0.5000         0    0.5000

get (gca, 'ytick')
ans =   -0.5000   -0.4000   -0.3000   -0.2000   -0.1000         0    0.1000    0.2000    0.3000    0.4000    0.5000

The stick values may imply that the tricks are related, but when I modify the stick property the rendered result does not change.  The plot is attached.

(file #31268)

Ben Abbott <bpabbott>
Project Member
Mon 28 Apr 2014 07:34:06 PM UTC, comment #3: 

This is great!  I haven't been able to get to this issue for over a year so I'm glad someone finally did.

Before you finalize the code I think we should check if there is a Matlab interface we should be trying to match.  If not, we can do whatever we want and create the new properties like rtick, ttick.  But maybe Matlab does something simple like re-using xtick for rho and ytick for theta?

Here are some other responses to your questions:
1) Yes, it is okay to use a tag.  We already do this for items like legends and contours.

2) We need listeners on all the properties that could affect the display.  I see

One thing that I think would make it easier is to use the extended version of addlistener to pass through the property name that is being updated and then you can get by with a single update_text routine and a single update_line routine.

For example,

addlistener (hax, "fontangle", {@update_text, hg, "fontangle"})
addlistener (hax, "fontangle", {@update_text, hg, "fontname"})

and later

function update_text (hax, ~, hg, propname)
  propval = get (hax, propname);
  htext = findobj (hg, "type", "text");
  set (htext, propname, propval);

There is a similar example from legend.m

function updatelegendtext (h, ~)
  kids = get (h, "children");
  htext = [];
  for i = 1:numel (kids)
    if (strcmp (get (kids(i), "type"), "text"))
      htext(end+1) = kids(i);

  tprops = {"fontangle", "fontname", "fontweight", "color"};
  lprops = {"fontangle", "fontname", "fontweight", "textcolor"};
  set (htext, tprops, get (h, lprops));

  ec = get (h, "edgecolor");
  set (h, "xcolor", ec, "ycolor", ec);

In this case, all display values are copied over regardless of which one changed.  It's not too compute intensive because the set() routine automatically shortcircuits if the old and new value are the same.

Rik <rik5>
Project Administrator
Mon 28 Apr 2014 06:09:31 PM UTC, comment #2: 

I've written a patch for this.
The documentation of the new properties "rtick" and "ttick" is still missing but I want to discuss implementation details first.

I create a hggroup as child of the axis with tag "polar_grid". Is it okay to use the tag property to identify the hggroup later?

Until now there are 4 listeners for "rtick", "ttick", "fontsize", "linewidth". Should I add other ones?

Does Matlab has the ability to switch the theta axis to radians?

-- Andy

(file #31267)

Andreas Weber <andy1978>
Project Member
Fri 16 Aug 2013 01:25:43 AM UTC, comment #1: 

It appears that the polar axes in Matlab are drawn using line objects.

polar (0,0)
findobj (gca, 'type', 'line')

ans =


findall (gca, 'type', 'line')

ans =


The white background and ticklabels are constructed using a patch and text objects.

get (findall (gca, 'handlevisibility', 'off'), 'type')

ans =


Ben Abbott <bpabbott>
Project Member
Tue 16 Jul 2013 05:10:26 PM UTC, original submission:  

When polar() is used to produce a plot the axis is still very much a rectangular Cartesian axis.  Matlab does a nice job of drawing circles of various constant radius as well as radii at various angles.  The constant 'r' curves are labeled with the distance from the center and the radii are labeled with their angle measures.

It seems like this would have to be created as some sort of hggroup which was a child of the current axis.  It only consists of some lines and text labels so it wouldn't be that hard to create.  It might have to have some listeners, however, so that if the axis linestyle, font, etc. were changed that the changes would be propagated through the hggroup.

Rik <rik5>
Project Administrator


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

Attach Files:

Attached Files
file #34367:  polar.png added by None (68KiB - image/png)
file #31665:  polar_fix6.diff added by dac922 (5KiB - text/x-patch)
file #31663:  Matlab-polar-first.png added by bpabbott (54KiB - image/png)
file #31660:  polar_fix5.diff added by dac922 (5KiB - text/x-patch)
file #31657:  Matlab.png added by bpabbott (47KiB - image/png)
file #31656:  polar_fix4.diff added by dac922 (5KiB - text/x-patch)
file #31620:  polar_fix3.diff added by dac922 (2KiB - text/x-patch)
file #31619:  polar_fix2.diff added by dac922 (2KiB - text/x-patch)
file #31605:  polar_fix.diff added by dac922 (1KiB - text/x-patch)
file #31268:  test.pdf added by bpabbott (9KiB - application/pdf)
file #31267:  polar_m.patch added by andy1978 (4KiB - text/x-diff)


Depends on the following items: None found

   bug dependencies.


Carbon-Copy List
  • -email is unavailable- added by godfrey (Posted a comment)
  • -email is unavailable- added by dac922 (Updated the item)
  • -email is unavailable- added by andy1978 (Updated the item)
  • -email is unavailable- added by bpabbott (Posted a comment)
  • -email is unavailable- added by rik5 (Submitted the item)

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

    Only project members can vote.




    Follow 15 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-07-02 None Attached File- => Added polar.png, #34367
    2014-07-02 dac922 Attached File- => Added polar_fix6.diff, #31665
    2014-07-02 bpabbott Attached File- => Added Matlab-polar-first.png, #31663
    2014-07-02 dac922 Attached File- => Added polar_fix5.diff, #31660
    2014-07-02 bpabbott Attached File- => Added Matlab.png, #31657
    2014-07-01 dac922 Attached File- => Added polar_fix4.diff, #31656
    2014-06-25 dac922 Attached File- => Added polar_fix3.diff, #31620
    2014-06-25 dac922 Attached File- => Added polar_fix2.diff, #31619
    2014-06-23 dac922 Attached File- => Added polar_fix.diff, #31605
    2014-05-11 rik5 StatusIn Progress => Fixed
        Open/ClosedOpen => Closed
    2014-04-28 bpabbott Attached File- => Added test.pdf, #31268
    2014-04-28 rik5 StatusConfirmed => In Progress
    2014-04-28 andy1978 Attached File- => Added polar_m.patch, #31267
    2013-11-16 rik5 Dependencies- => bugs #40588 is dependent

    Back to the top

    Powered by Savane 3.5