rudimentary tick positions

Shai Ayal shaiay at gmail.com
Mon Feb 4 23:39:44 CST 2008


On Feb 5, 2008 12:03 AM, Michael Goffioul <michael.goffioul at gmail.com> wrote:
> On 2/4/08, Shai Ayal <shaiay at gmail.com> wrote:
> > attached is a patch for rudimentary tick position calculations. It is
> > a translation of Tom Holroyd's python code which he posted to this
> > list some weeks ago (Tom, I hope that by posting the code here you
> > agreed to it's use in octave ...).
> > What is missing is:
> > *) log axes ticks
> > *) minor ticks
> > *) does not take into account the axes size and font size to eliminate
> > tick overruns
> > *) gnuplot interaction
> > *) your favorite feature here
> >
> > Still, I think it is good enough to serve as a basis to the above improvements.
>
> Shouldn't autoscale and autotick be combined (axis limits are extended to
> the next tick)?
>
> I was thinking about something like (in algorithmic language):
>
> if (axis_mode == "auto")
>   limits = get_raw_limits(); // compute raw limits based on children
> else
>   limits = get_manual_limits();
> tick_step = get_best_tick (limits);
> if (axis_mode == "auto")
>   limits = extend _limits_to_next_tick (limits, tick_step);
> ticks = compute_ticks (limits, tick_step);
>
> Michael.
>

Well, we already have get_axis_limits in graphics.cc which attempts to
find the "nicest" limits, So the limits are probably "nice" by the
time we get to calc_ticks. However I will look at them to see that
they are "compatible" in the sense that they both agree on the meaning
of "nice"

Shai


More information about the Octave-maintainers mailing list