Pages

06 February 2013

332. Gnuplot: bug(?) in current debian testing package

Update 2:
"Note that gnuplot uses both "real" and "integer" arithmetic, like FORTRAN and C. Integers are entered as "1", "-10", etc; reals as "1.0", "-10.0", "1e1", 3.5e-1, etc. The most important difference between the two forms is in division: division of integers truncates: 5/2 = 2; division of reals does not: 5.0/2.0 = 2.5. In mixed expressions, integers are "promoted" to reals before evaluation: 5/2e0 = 2.5. The result of division of a negative integer by a positive one may vary among compilers. Try a test like "print -5/2" to determine if your system chooses -2 or -3 as the answer."

http://www.physics.drexel.edu/courses/Comp_Phys/General/Graphics/gnuplot.html

I guess it's a feature. I guess I just need to remind myself of it every now and again...

Update: version 3.7.3 behaves the same way.


I use gnuplot for fitting data for scientific publications and every time I discover a bug it makes me seriously worried that I've somehow published something which will turn out to be incorrect.

It's not without reason -- Gnuplot version 4.4.0 in Debian Testing garbled small and large numbers: http://verahill.blogspot.com.au/2012/02/debian-testing-wheezy-64-bug-in-debian.html

I'm not sure whether this is a bug, but gnuplot 4.6.0 (current version in debian testing) screws up fractional powers.

gnuplot> print 9**(1/2)
1
gnuplot> print 9**(0.5)
3.0
gnuplot> print sqrt(9)
3.0

Somehow this works:
gnuplot> print 10**(2)
100
gnuplot> print 10**(2.0)
100.0
gnuplot> print 10**(6/3)
100
but not this
gnuplot> print 10**(1)
10
gnuplot> print 10**(1/2)
1
gnuplot> print 10**(1/3)
1
gnuplot> print 10**(0.3333333)
2.15443452467292
gnuplot> print 10**(1/3.0)
2.15443469003188

So the error seems to be due to the usual issue of distinguishing between integer values and real values e.g. the following example in Python 2.7:
>>> print 1/3
0
>>> print 1/3.0
0.333333333333

I still don't think this is intended behaviour in gnuplot, and it's certainly dangerous

Upstreams version 4.6.1
wget http://downloads.sourceforge.net/project/gnuplot/gnuplot/4.6.1/gnuplot-4.6.1.tar.gz
tar xvf gnuplot-4.6.1.tar.gz
cd gnuplot-4.6.1/
./configure --program-suffix=-4.6.1 --prefix=$HOME/.gnuplot-dev
make
make install
cd $HOME/.gnuplot-dev/bin
./gnuplot-4.6.1

gnuplot> print 9**(1/3)
1
gnuplot> print 10**(1/3)
1
gnuplot> print 10**(6/3)
100
gnuplot> print 10**(3/6)
1

2 comments:

  1. It is dangerous! I stayed up for whole night trying to find a mistake in my plotted function but it was due to this problem...

    ReplyDelete
    Replies
    1. Thanks for the feedback. Yes, I think it would be appropriate with a couple of warning messages pointing out that there's potential for ambiguity. Also, is this even desired behaviour? Wouldn't it make sense that the output itself from any operation involving a system like this (e.g. f(x)=x^(2/3) ) would only be allowed to return integer values? At least that way this behaviour would be a bit more discoverable.

      I mean, I can see WHY it happens. But I still don't think it's a desired behaviour.

      Delete