Attached is a quick changeset that doesn't display the rtick value of 0, but doesn't alter the 'rtick' property.

Interestingly, polarplot on Matlab does not display small values that are lower than 1e-9 times the largest value in rticks.  That looks like the precision of a single value which is what OpenGL uses.

(file #55447)

Reviewed and made a few tweaks in this changeset https://hg.savannah.gnu.org/hgweb/octave/rev/2cf4c5bfc410.

The only important change was that a %!test block had several groups of tests and at one point there was a blank line in between the groups.  The blank line ends the %!test block so the remaining tests just looked like commented out code.  I fixed that.

Marking bug as Fixed and closing report.

made a set of BISTs for the current version of polar, verified the pass a make check and pushed to stable as
https://hg.savannah.gnu.org/hgweb/octave/rev/a3e17876a05b

will work up feature change to polar and add/adjust tests as necessary for dev.

I changed the category from "Incorrect Result" to "Matlab Compatibility" since there is nothing incorrect about excluding the zero point, just a choice.

I do agree that the fix is simple, Matlab-compatible, and worth doing.

Because this is more of a feature request, and doesn't cause an error in Octave, I would put the changeset on the development branch rather than the stable branch.

rtick and ttick work on polar plots by pulling the appropriate values from xtick or ytick, and inserting those into the appropriate property in the polar object.  i noticed that rtick doesn't contain the 'zero' value when the plot is created, but if the rtick values are manually specified later with 'rticks', it contains and returns that as part of the tick range.

Our implementation for polar operates a bit outside of any direct compatibility concerns, but in matlab 'rticks' on polarplot objects always returns the center (zero) value as part of rtick points.

Even though Matlab does not permit rticks to apply to polar plots (which have no rtick property) the thought on extending octave with those properties/functions seemed to be that that later when polarplot objects are implemented in octave, the same functions could just be overloaded there and behavior should be consistent/compatible.

I'd recommend we update rtick to always return the 0/center value. It turns out it's a very simple one character change in polar, changing line 176 calculation of the lower index from > to >= so it also pulls the 0 value from xtick. I.e:

minidx = find (xtick >= 0, 1);

behavior before change:

>> t = [0:15:180] * pi / 180;
>> r = sin (t);
>> polar (t, r)
>> get (gca, 'rtick')
ans =

   0.5000   1.0000

>> rticks (gca, [0 .5 1])
>> get (gca, 'rtick')
ans =

        0   0.5000   1.0000

behavior after change:

>> t = [0:15:180] * pi / 180;
>> r = sin (t);
>> polar (t, r)                  ^
>> get (gca, 'rtick')
ans =

        0   0.5000   1.0000

>> rticks (gca, [0 .5 1])
>> get (gca, 'rtick')
ans =

        0   0.5000   1.0000

i'll attach a patch to do that once this generates a bug number, check demos and maybe add a couple tests for polar.

would also like to verify that this is something that should go on default, not stable (for 9.1), and will write a news note accordingly.