**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) 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.