On Wed, 2005-03-23 at 11:01 -0800, Ethan Merritt wrote:
> On Tuesday 22 March 2005 01:01 pm, Aapo Lankinen wrote:
> > same colour. I removed the other de-log, and following patch fixes the
> > problem at least for me. :-)
> Thanks. Applied in cvs.
You're welcome. However, I found a new bug in the Gnuplot 4.1 CVS
logarithmic contours code. The following script doesn't work as
---- clip ----
set log z
set palette model HSV functions gray, gray, 0.8-0.5*gray
set log cb
set view map
set cntrparam level incremental 5,2,200
splot x**2+y**2+1.0 palette
---- clap ----
Nothing is plotted. The problem is in the "cntrparam level incremental"
definition; Gnuplot recognizes the values as linear increments in
logarithmic axis, which leads in HUGE steps in the actual z-value. The
steps go like (10^5, 10^7, 10^9, ... , 10^200), which is obviously very
By replacing the "set cntrparam" command with
"set cntrparam level incremental 1,0.1,2"
one gets a nice plot with z range [10:100] (10^1 and 10^2) with ten
contours (1/0.1). This works, but is very confusing for the end user.
One thing to note is that it's not generally quite clear what is meant
by "cntrparam level incremental" in logarithmic space. I assume that
the user means constant increments in logarithmic space. However,
because addition in logarithmic space means multiplication in linear
space, there will be a problem: What is the multiplicator (i.e. the
logarithmic addition)? The incrementation parameter is not usable, as
it should mean an incrementation in linear space, not multiplication.
I wrote a small patch based on the interpretation of constant increments
in logarithmic space. In the patch, the incrementation in logarithmic
space is calculated so that the first incremental step (in linear space)
is exactly as large as the incrementation the user selected. I chose
that implementation, because
a) it's intuitive
b) it's simple to program
c) it doesn't seem to break the existing, correct implementation for
linear z axis.
So, the new patch should give contours in z positions (5, 7, 9.8, 13.7,
19.2, ...) for "set cntrparam level incremental 5,2,200". The idea is
that 5 + 2 = 7, so that the first two steps are the same as for the
linear case, and the next steps are calculated logarithmically based on
the first two. I hope that is intuitive enough; at least it's lot
better than the current behaviour. The main problem is that it doesn't
draw anything with negative values (which do not have real logarithms
anyway). Well, at least it doesn't dump core either. :-)
The very very small patch to implement this is attached, please try it
for the example above to see what I mean. I've tried it with simple
linear and logarithmic scripts (like the sample above), but who knows?
It may break something; works for me, but YMMV. :-)
> You're welcome. However, I found a new bug in the Gnuplot 4.1 CVS
> logarithmic contours code. The following script doesn't work as
As so often, that depends on the background of the person doing the
The right way of handling this would have been to do it like the other
"tick series" things in gnuplot do it, i.e. like 'set xtics'. Which
means the endpoints are numbers in the input format, but the increment
is a *factor*, not an addition to the logarithm.
So '5,2,200' should have delivered tics at (5,10,20,40,80,160)
> One thing to note is that it's not generally quite clear what is meant
> by "cntrparam level incremental" in logarithmic space.
Taking into account prior art, it is. It just fails to be implemented
that way ;-(
On Tue, 2005-06-07 at 19:52 +0200, Hans-Bernhard Bröker wrote:
> As so often, that depends on the background of the person doing the
> The right way of handling this would have been to do it like the other
> "tick series" things in gnuplot do it, i.e. like 'set xtics'. Which
> means the endpoints are numbers in the input format, but the increment
> is a *factor*, not an addition to the logarithm.
That's cool. I made a new patch that implements it that way.
> So '5,2,200' should have delivered tics at (5,10,20,40,80,160)
Now the z ticks are exactly like that. And the patch is even
> Taking into account prior art, it is. It just fails to be implemented
> that way ;-(
Ok, thank you. I don't have very deep knowledge of Gnuplot, so I didn't
realise that. But now it's fixed, see the attached patch.