Is it possible to set Y-axis to integer only

[liny...@gmail.com]

Hi,

Is it possible to set GnuPlot Y-axis to integer only (gnuplot 4.6 patchlevel 0) so that the minimum step would be 1 (minimum only, not default)?
In some cases, like in here amount of bugs that I count, value can only be integer.
Instead Y-axis values are decimals if difference is 1 (see bugs.txt I).

I do not want use "set ytics 1" since that will mess up Y-axis values when difference of two values is higher (see bugs.txt II).

This is not a big deal, but a bit annoying.
Thanks.


plotdata.txt:
-------------
set key off
set term png
unset xtics

date=system("date +'%d-%b-%Y %H:%M'")

# Last 7 days
set output 'bugs/bugs-week.png'
set xlabel "days: 7 (" . date . ")"
plot "< tail -7 bugs/bugs.data" using 2 with lines

bugs.txt I:
-----------
2012-12-17_12:10:01 100
2012-12-18_12:10:02 100
2012-12-19_12:10:02 100
2012-12-20_12:10:02 100
2012-12-21_12:10:02 100
2012-12-22_12:10:02 100
2012-12-23_12:10:02 101

bugs.txt II
-----------
2012-12-17_12:10:01 100
2012-12-18_12:10:02 100
2012-12-19_12:10:02 100
2012-12-20_12:10:02 100
2012-12-21_12:10:02 100
2012-12-22_12:10:02 100
2012-12-23_12:10:02 201

[Karl]

If you set a minimum range

set yr [*<-10:10<*]

that´s large enough, you should never get ticlabels that aren´t integer.

hth.

Karl

[liny...@gmail.com]

Thanks for a quick answer, Karl.

That does work too but problem is that now it really sets the range instead just minimum step.
In case I have bigger values, 10000-10001, range is now 0-10001, so the change from 10000 to 10001 is not even visible.
And I would like keep the range automatic (so in here min 10000 and max 10001) but step would be 1.

I hoped there was some simple setting like "set yinteger".

Really not a problem, but just annoying to see amount of bugs in decimal points :)

[Karl]

Am 07.01.2015 um 12:18 schrieb liny...@gmail.com:
>
> That does work too but problem is that now it really sets the range instead just minimum step.
> In case I have bigger values, 10000-10001, range is now 0-10001, so the change from 10000 to 10001 is not even visible.
> And I would like keep the range automatic (so in here min 10000 and max 10001) but step would be 1.
>
> I hoped there was some simple setting like "set yinteger".
>
> Really not a problem, but just annoying to see amount of bugs in decimal points :)

Yes, I see what you mean. More generally, you want to set a minimum tic
increment, in your case of one. That´s not implemented. You might want
to set up a feature request on gnuplot.sf.net

You can however use "refresh"

plot $data
delta = GPVAL_DATA_MIN_X - GPVAL_DATA_MAX_X
set ytics (delta == 0 ? 1 : 10**(int(log10(delta)+.2)))
#alternatively
set yrange [*<GPVAL_DATA_MIN_X-10 : GPVAL_DATA_MAX_X+10 < *]
refresh

to change the tic/range settings for your current plot and update it
without re-reading the data.

Karl

[liny...@gmail.com]

Exactly, minimum tic increment.
I have now sent feature request to the developers.

After doing quite a lot testing with this I still could not get to work.
Good side is that I learned heck of a lot :)

This was as close I could get:

# dummy plotting to set GPVAL-variables
plot "< tail -7 bugs.data" using 2 with lines

# some of these values will be RESET if set before dummy plotting!
unset xtics

set key off
set term png

set output 'bugs-week.png'
set xlabel "dayz: 7 (" . system("date +'%d-%b-%Y %H:%M'") . ")"

# works just as wanted, except if all data is zeros, then ERROR!
maxy=(GPVAL_DATA_Y_MAX - GPVAL_DATA_Y_MIN < 11 ? 10 : GPVAL_DATA_Y_MAX)
set yrange [GPVAL_DATA_Y_MIN:maxy<*]
refresh

As I put in the comments, some weird behavior was found.
Some of the settings were reset and had to be set again after plotting, atleast set output 'filename', so I do the dummy plot first and then set all things.
Another weird thing, and one that prevents me to use this solution, is yrange autoscale.
If data contains only zeros, autoscale fails:
"plotdata.txt", line 14: y_min should not equal y_max!
It fails although I set "minium of maxy and autoscale" where maxy is atleast 10.
This fail happens only with "refresh".
If I do same yrange setting before "normal" plotting, it works as should.
Sounds like a bug to me...

If I leave autoscaling out "set yrange [GPVAL_DATA_Y_MIN:maxy]" it works, but outcome is not as nice as the top value is missing from Y-axis.

Pity, since otherwise I finally got it exactly as I wanted:
integer stepping and never below 0 (no split nor negative bugs).

Thanks for the examples and help!

[Karl]

sure is (i tested with gp460), check

show yrange

after "set yrange".

But it seems to be long fixed. The recent gnuplot 466 works correctly,
as does gp5.0. Why are you using that old version? debian wheezy? You
could try wheezy-backports, it has version 466, or just compile the
newer version (466 or 500) yourself.

About your comment "some of these values will be RESET if set before
dummy plotting!" : You surely should set the png terminal only directly
before "refresh", otherwise you plot twice to the same png file. That´s
bound to give trouble and undefined results. But the rest should be OK.
Which setting is it that isn´t kept?

K

[liny...@gmail.com]

confirmed.
460: set yrange [ 0.00000 : 10.0000 < * ] noreverse nowriteback # (currently [:1.00000] )
466: set yrange [ 0.00000 : 10.0000 < * ] noreverse nowriteback # (currently [:2.00000] )

Yes, I am using Debian Wheezy.
And right again, when I upgraded from Backports to 466 that problem was gone (excellent!).
In my homepage server they also use Debian Wheezy but I cannot affect the gnuplot version.
Had to try if I could simply use new binary, but its a no go (surprise), libraries should be upgraded too :)
But anyway, at home things are finally working.

About that reset thing, I cannot reproduce it anymore.
Hmmm, maybe this time it was me that had malfunction :)
It was that "set output filename" that I had the problem with.
Could it been because I was misusing the "set term".
I changed the code to following and its working perfectly now with 466:

# dummy plotting to set GPVAL-variables

set term unknown

plot "< tail -7 bugs.data" using 2 with lines

# outlook

unset xtics
set key off
set term png
set output 'bugs-week.png'

set xlabel "days: 7 (" . system("date +'%d-%b-%Y %H:%M'") . ")"

# no decimal points nor negative values in Y-axis

maxy=(GPVAL_DATA_Y_MAX - GPVAL_DATA_Y_MIN < 11 ? 10 : GPVAL_DATA_Y_MAX)
set yrange [GPVAL_DATA_Y_MIN:maxy<*]
refresh

Again, big thanks for all your help!

[Karl]

Am 08.01.2015 um 20:22 schrieb liny...@gmail.com:

> Yes, I am using Debian Wheezy.
> And right again, when I upgraded from Backports to 466 that problem was gone (excellent!).
> In my homepage server they also use Debian Wheezy but I cannot affect the gnuplot version.
> Had to try if I could simply use new binary, but its a no go (surprise), libraries should be upgraded too :)
> But anyway, at home things are finally working.

Gp466 should compile out of the box on wheezy, i´m pretty sure i
remember doing it myself with 464 or 465.

> I changed the code to following and its working perfectly now with 466:
>
> # dummy plotting to set GPVAL-variables
> set term unknown
> plot "< tail -7 bugs.data" using 2 with lines

Instead of plotting to the ugly "unknown" terminal, you could use
"stats". Very useful (not here exactly, but in general).

> # outlook
> unset xtics
> set key off
> set term png
> set output 'bugs-week.png'
> set xlabel "days: 7 (" . system("date +'%d-%b-%Y %H:%M'") . ")"

If you want to do that without the (slow) system() call, there´s a gp
function time() that returns the current system time:

print strftime("%d.%m.%Y %H:%M:%S",time(0))

> # no decimal points nor negative values in Y-axis
> maxy=(GPVAL_DATA_Y_MAX - GPVAL_DATA_Y_MIN < 11 ? 10 : GPVAL_DATA_Y_MAX)
> set yrange [GPVAL_DATA_Y_MIN:maxy<*]
> refresh
>
> Again, big thanks for all your help!

You´re welcome.