Dear gnuplot developers,
// first, many thanks for this marvelous sw package, I have been using it
for school, work and fun ~10 years, and I am constantly astonished by the
quality and the fact, how clever subset of functionality it has.
Now, I would like to consult with you an algorithm for automatical tic
size choice, as present in quantize_normal_tics() last years. I have been
in need of some user interface plotting for a cardiologic realtime
analysis software, written in Athena/Xt GUI. I proposed an algorithm for
auto tics, then, I looked into gnuplot for a comparison.
Since my own algorithm seems to me to be possibly slightly better, I would
like to share the idea. The code snippet is:
float tic_quant[] = {5.0, 2.0, 1.0};
int n_min = 5, n_max = 10;
float quantize_tics(float y_min, float y_max)
{
float f, d;
int i, m, n;
f = log10((y_max  y_min)/n_max);
for (i = 0; i < length(tic_quant); i++) {
m = ceil(f  log10(tic_quant[i])  FLT_EPSILON);
d = tic_quant[i]*pow(10, m);
n = ceil(y_max/d)  floor(y_min/d);
if (n >= n_min)
break;
}
return d;
}
The tic size is always tic_quant[i]*10^k, k \in Z. Number of intertic
spaces (intervals) n obeys strictly n_min <= n <= n_max. The algorithm can
be tuned by variation of tic_quant[] and n_min, n_max. However, it should
be assured, that for chosen n_min, n_max the algorithm will always find a
solution.
It should be noted, that the function uses both bounds of desired axis
range, not only the interval between. The purpose is to assure n_min,
n_max, what can not be achieved, when only the interval is known. Thus, it
can not serve as a dropin replacement of quantize_normal_tics(), or it
can, but the n_max may be overshot by one.
What do you think about this way? If you recommend it, I can prepare a
patch to prove the idea.
Best regards,
Marek
