## gnuplot-beta

 Proposal for quantize_normal_tics() algorithm replacement From: Marek Peca - 2010-06-13 21:32:29 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 real-time 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 drop-in 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