So why am I getting the same results for each test?

Wait and see what happens when some more Windows users come on line to try it. If some of them have the same results as you then it is a real question mark as to what is going on.

I confirm Wallace's tests: both results are 0 using Windows 7 32-bits

What is going on anyway?

Sometimes, I get a zero result from the spinner in Linux. More often than not, I get a non-zero result.

For Windows users, I'd guess you'd have to run the test quite a few times to be sure that you never see a non-zero result. What appears to be happening is that when the spinner is used to move to zero, the value it's not being set to exactly zero all the time. Why, is a mystery.

When you're writing scripts expecting the input to be exactly zero, you'd better get exactly zero or bad things can happen.

Looks like it is narrowed down to 32 bits and 64 bits on windows. I think we need another windows 64 bit test now.

Yes. You want to see zero in all cases.

All the script is doing is printing out that value entered. So far, we can confirm that Linux is displaying the incorrect (non-zero) value most of the time. Unless Molly is mistaken, she has reported that she got the incorrect (non-zero) value in both Linux and Windows.

You and dinasset have reported that you always get zero in Windows, which is what you should be getting.

All this script does is display the input slider/spinner (which is a predefined Script-Fu procedure) and then prints the results when you click OK. That's it. Whatever is happening is something internal to GIMP/Script-Fu.

It's possible that it doesn't affect Windows but I doubt that's the case. This is not the first time I've ran across these kinds of strange things and sometimes, it's just harder to confirm the weirdness is occurring across all OS's.

Here's another example of a bug that cannot be consistently reproduced in Windows and Linux, but it's there.

Strange...

Here's a variation of the test on Linux.
1. Spinner set directly to 0
Test Zero Warning
Value: 1.387778781e-16

2. Spinner advanced to 1.1 and then to 0
Test Zero Warning
Value: 0

The second result was consistent using other +1.0 values before running the test at 0. I've run this test using reset between #1 & #2 and only running test #2 on a new image.

Went back to windows again and ran 4 times with the spinner and 4 times with the slider.
Here are my results. The top window was with the spinner and the bottom with the slider.

Ok, thanks Molly. That confirms the bug is occurring in both Windows and Linux.

I created a little video that demonstrates how using the spinner to set to zero sometimes displays the correct value and sometimes doesn't.

I have run this several times. The first time I got a non-zero value with the spinner, zero with the slider. Second time I got non-zero value with the spinner, without restarting GIMP I set to a value with the spinner, then zeroed with the slider and got a non-zero value. Every subsequent attempt I have zero both ways. (I close and re-open GIMP between each test.)

This is with Ubuntu 14.04LTS and GIMP 2.8.

I shall leave the computer running and check later if you wish me to do further tests.

david.

@David - Thanks for testing. I'd say we have enough Linux tests to confirm that there is something wrong here.

@Odin - You're right. If I move the spinner up, then back down to zero, I get a zero result. I also noticed when moving the slider and the spinner up and down, then using the spinner to move to zero, I sometimes get a really outlandish result, like this:

Test Zero Warning
Value: 4.718447855e-15

Looks like it is a GTK problem after all (as my first tests suggested, but later tests counter-suggested!)
I've now hacked a copy of the Script-Fu plugin to show the actual double float values returned from the GTK spinbutton.
Starting at 1.0 (indicated) and stepping down (in steps of 0.1), these are the values actually passed to the Script-Fu plugin:
1.00000000000000000000
0.90000000000000002220
0.80000000000000004441
0.70000000000000006661
0.60000000000000008882
0.50000000000000011102
0.40000000000000013323
0.30000000000000015543
0.20000000000000014988
0.10000000000000014433
0.00000000000000013878
-0.09999999999999986677
-0.19999999999999987232
-0.29999999999999987788
-0.39999999999999991118

Linux 64-bit:

Things seem to work fine on 32-bit GNU/Linux; it is only on 64-bit GNU/Linux that the anomalous behavior was exhibited. I'd expect the same is true on Microsoft OSes, but have no way of testing.

The 'spin up' button on the spinner appears to be the culprit that actually introduces the "imprecision". That is to say, starting from a "precise" value, the 'spin down' button by itself never seems to result in the near-zero anomaly. There is no way to see that the imprecision has been introduced, other than by spinning it down to zero.

Explicit numeric entry, slider stepping, and slider dragging all result in a precise value being set -- after the value has been set using one of these methods, the near-zero anomaly will not occur by using the spin down button. It is only when a spin up button press is introduced into the flow that the possibility of the near-zero anomaly exists (even though it can only become apparent by following the spin up with a spin down).

I have looked at the Script-fu source code and see nothing amiss. It would be interesting to see the same testing performed with Python-fu. I suspect that this is a problem with GTK+ and that somewhere a float value is being read as a double (or a double is being read as a long double).

My results