[Octave-bug-tracker] [bug #64991] polar doesn't populate rtick with center tick value

[Nicholas Jankowski]

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

                 Summary: polar doesn't populate rtick with center tick value
                   Group: GNU Octave
               Submitter: nrjank
               Submitted: Wed 06 Dec 2023 05:16:42 PM EST
                Category: Plotting
                Severity: 2 - Minor
                Priority: 5 - Normal
              Item Group: Incorrect Result
                  Status: None
             Assigned to: None
         Originator Name: 
        Originator Email: 
             Open/Closed: Open
                 Release: 8.4.0
         Discussion Lock: Any
        Operating System: Any
           Fixed Release: None
         Planned Release: None


    _______________________________________________________

Follow-up Comments:


-------------------------------------------------------
Date: Wed 06 Dec 2023 05:16:42 PM EST By: Nicholas Jankowski <nrjank>
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.







    _______________________________________________________

Reply to this item at:

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

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