Mon 06 Jul 2015 11:31:57 PM UTC, comment #27:
Rik:
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.
|
Fri 03 Jul 2015 05:02:11 PM UTC, comment #26:
I see the problem. This on the development branch with
The command, in verbatim mode for the bug tracker, is
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.
|
Thu 02 Jul 2015 10:59:32 PM UTC, comment #25:
I get attached picture. Looks ok for me.
(file #34367)
|
Thu 02 Jul 2015 03:39:14 PM UTC, comment #24:
It appears that this patch has broken the polar plot
in the Manual.
Just:
polar (0:0.1:10pi, 0:0.1:10pi);
previously produced the plot in the Manual
|
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)
|
Wed 02 Jul 2014 12:50:48 PM UTC, comment #22:
Ive attached the result from Matlab for the commands below.
(file #31663)
|
Wed 02 Jul 2014 12:08:11 PM UTC, comment #21:
Ok, for plot->polar the axis rescales. What happens for polar->plot?
With attached diff, this example doesn't rescale.
(file #31660)
|
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.
|
Wed 02 Jul 2014 12:45:37 AM UTC, comment #19:
I've attached the result from Matlab.
(file #31657)
|
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:
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)
|
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.
|
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)
|
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'.
|
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.
A solution could be to replace the 'oldxlim' stuff with following lines:
|
Wed 25 Jun 2014 10:01:51 PM UTC, comment #13:
The patch is almost there. Changes I see
1) Re-instate
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
4) get (gca, 'xlim') is bound to return something. I think you can remove the if test that has a comment on it.
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
|
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)
|
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.
|
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.
|
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
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
|
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:
|
Tue 24 Jun 2014 11:42:37 PM UTC, comment #7:
What does Matlab do for
I'm looking at the documentation
and I can't see that this form matches. Maybe the input validation routines need to be improved so that an error is generated.
|
Mon 23 Jun 2014 06:51:26 PM UTC, comment #6:
There are some problems with new polar plot. Following code produces an error:
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)
|
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
to change axis lines and labels.
We invented the rtick, stick properties. Should we also invent rcolor and scolor to refer to these properties?
|
Mon 28 Apr 2014 09:56:04 PM UTC, comment #4:
I ran a simple example using Matlab.
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)
|
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
color
linewidth
font{angle
name
size
units
weight}
interpreter
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,
There is a similar example from legend.m
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.
|
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)
|
Fri 16 Aug 2013 01:25:43 AM UTC, comment #1:
It appears that the polar axes in Matlab are drawn using line objects.
The white background and ticklabels are constructed using a patch and text objects.
|
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.
|