"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) 100but 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
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...
ReplyDeleteThanks 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.
DeleteI mean, I can see WHY it happens. But I still don't think it's a desired behaviour.