The example below shows that despite the clear intention of these both being evaluated as real expressions by the use of the 3.0 constant in the front, the (3/2) sub-expression is still evaluated as integer. This is counter-intuitive and contrary to virtually all modern interpreted languages where use of a real-valued expression type-coerces the entire expression and all sub-expressions to real-value. Integer evaluation should only be used if integer valued components are used through-out an entire expression:
gnuplot> print 3.0**(3/2) 3.0 gnuplot> print 3.0**(3./2) 5.19615242270663
The gnuplot FAQ does warn about integer vs real valuation, but does not state that it applies at the sub-expression level and that no type-coercion is performed.
This bug is in both 4.6 and 5.0.
This is not a bug, it's documented behaviour.
gnuplot clearly states that its arithmetic is modelled after C, not after whatever the latest "new" language happens to do. Oh, and just FTR, by your logic, Python is not a modern interpreted language. Well either that, or you completey misunderstood what type-coercion means.
Agreed 3/2 = 1
If you don't know what an integer is, use Excel.
Last edit: Clark Gaylord 2015-07-28
Why, yes, we could consider python to be the exception that proves the rule ;-)
And, citing C rules (with it's strong-typing warnings at compile-time) somehow doesn't seem really useful in a silently-interpreted environment, even if literally true.
Well, perhaps consider then as a feature request, as the inadvertent embedding of integer sub-expressions in an otherwise real-valued expression almost always silently leads to unintended consequences.
Ruby also pokes a hole in your expectations:
So what languages were you thinking of?
Gnuplot is clearly not a "modern interpreted language", as it was designed 30 years ago. Please think of math in gnuplot as working like math in C/C++.
That said, I think your expectations about "virtually all modern interpreted languages" may be overly broad.