Beg to differ, Saul.
The list of values I posted above started at 1.0 (the preset value for the spinbutton) and stepped-down only. At no point did I press the up button. And I've just tried it again from Gimp restart - the anomaly does arise using only the down button.

Interesting. I was unable to coerce the near-zero value when I tried spinning down from a precise value, but your test shows that it is possible. Perhaps I did not try it enough times.

After my entry above (No. 35) I shut down the computer, rebooted, open GIMP again and repeated the test several times. For some of them I closed and re-opened Gimp, for others I used the reset button. The result was always zero. I left the computer running for about 1 hour (GIMP closed), re-opened GIMP ran the test again and got a non-zero result. Numerous retries were all zero.

I am using 32 bit Ubuntu incidentally.

I do not know if this is of any help. However, if I can do anything useful, just ask.

david.

edit: I have used the "up" button to start with values of 0.5, 0.4, 0.3, 0.2, 0.1 and in each case decremented down in steps of 0.1. All results correct until I hit zero when the result is always 2.775557562e-17. I have also entered the start value of 0.5 using the keyboard and then decremented down with the same result.

Gnutux, just a curiosity:
did you try whether the result would show always 0 if in the gimp-message you place in front of the value the (inexact->exact) cast operator?

Good detective work, jon & saul.

I wonder if this has already been filed as a bug report?

@dinasset - Have you tried it? I checked it out in the console and it was expecting an integer.

I suppose a work around would be to round to the number of decimal places corresponding to the precision specified in SF-ADJUSTMENT.

Sorry GnuTux,
I didn't try because on my PC result is displayed correctly, but you are perfectly right: that cast applies only to integers.

GnuTux
I know it sounds strange, apparently, but I have another "silly" suggestion:
try to replace the gtk dll's of gimp release 2.8.14 with those on gimp 2.8.10
I recall my problem with document history, which was solved that way
("just to let other people curious on this aspect know the follow-on:
-made some other test
-discovered that it's the .dll related to gtk which causes this problem (it has been changed between 2.8.10 and 2.8.14)
-by overwriting the version of that .dll present on 2.8.14 with the one present in 2.8.10, the history is kept as expected.")
I say that because on my PC results are precisely 0.
Just a try should be simple (only keep aside the dll replaced for safety...)

Not much point in doing this as I observe the same behaviour using GIMP 2.6.7

GnuTux, here my two results. First I put the slider to 0; Then reset and set the slider to 0.

Yes, I don't think this line of enquiry is really going to get us very far.

It would seem that there is indeed a bug in GTK which can produce these anomalous results but I cannot see from the source code precisely where it's happening, so (unless this is already a known bug) to get a handle on the problem, somebody is going to have to hack and compile GTK from source. And I don't really want to do that right now!

But this is rather missing the point: even if we do mend GTK, or put a workaround for the problem into the GimpChat Script-Fu Extension plugin, that's still going to leave a problem for anybody using legacy versions or the standard Script-Fu Extension as supplied with Gimp.

We already know that Script-Fu input parameters may have to be sanitized before use - as we've seen on a number of occasions, even if the range for SF_ADJUSTMENT only allows integer values, if the slider is used, the value supplied to the script may be a full-precision float.

So I think, for the sake of robustness, we really need to extend and generalize the principle of "sanitizing" input values thus:
- float values can be used as supplied to the script;
- integer values must be sanitized by rounding or truncating;
- other numeric values (ie. numbers with a decimal fraction, but not float) must be sanitized by rounding or truncating to the nearest step-point.

I see GnuTux has already posted a (round-decimal ) function which is pretty much what I was going to suggest.

I can't find anything on bugzilla relating to this problem and the only thing Google comes up with is this item by some chap called Linus Torvalds (whoever he is):
http://lists.subsurface-divelog.org/pip ... 01623.html

Jonathan,
if:
1-you try my silly suggestion
2-you are able to get always exact values
3-you may find out -by comparison- what's wrong with gtk.dll version for 2.8.14
if...if...if...

GnuTux,
which version of gimp are you using? if it is the latest 2.8.14, you may -you too- perform the double-check test of using 2.8.10 version, for GTK at least.
BTW, Wallace is using 2.8.10...

@dinasset - paynekj has reported the problem exists in versions of GIMP going all the way back to V2.6.x. I think it was also mentioned that the issue might be confined to 64bit versions, although I'm not sure that has been confirmed. I do have a VM running 32 bit Linux that I'll can test with.


Well, looks like Linus pointed out issues with the spinner at one point. Doesn't look as though the problems have been addressed. Perhaps this issue could be brought to the attention of the GIMP devs on their mailing list. It might be a good idea to hear what they think.

It's always good idea to sanity check input but when zero is displayed on a dialog, I don't think coders would think to check to see if that zero was actually zero. I know I wouldn't. If it shows zero on the dialog, one would assume it's zero. It's kinda hard to believe this issue hasn't reared its ugly head before now. Or, maybe it has and it just so happens that no one has noticed until now.

because the test is very quick (either replacing the gtk dll taking it from 2.8.10 or testing directly on 2.8.10) I think it could be interesting to do it, to double-check; in fact paynekj didn't say that the error was there "all the way back to 2.6.x", he just said that it was there in v.2.6.x;
so, if you can, it could be interesting to check whether the error was solved -maybe by accident- in 2.8.10, and came back in 2.8.14...who knows
should this be the case then jonathan can compare the code of the two versions of the dll...

I was the one who reported that I could not produce the anomaly in 64-bit GNU/Linux. From scanning the findings of others, this mostly seems to be true; however, david has noted the near-zero problem happening on 32-bit Ubuntu.

Ah, I missed that.. Thanks.

So, now that we have confirmed that a problem exists, what do you recommend as the next step to take?

Hate to be bearer of bad news but.. methinks you are expecting a bit too much of the cosseted environment provided by Script-Fu. This is floating-point arithmetic and it is, therefore, imprecise by nature, as this simple exercise on the Script-Fu Console demonstrates:

The while loop just adds 0.1 to a variable ("x") 1000 times over, starting from zero. At the end of the loop, I have displayed the value of x, and sure enough it shows as "100.0" which is what you would expect. However, if we then use (= ) to test whether the variable is actually equal to 100.0, we get the answer false! And if we subtract 100.0 from the variable it now shows a very small (and previously invisible) residual value, a remnant from all that floating-point addition.
If you try the same exercise but adding 0.125 (ie. 1/8) each time, you get no such residual:

The reason for this discrepancy is that 0.1 is not a precise binary fraction ..it is a precise decimal fraction.
The precise binary fractions are 1/2, 1/4, 1/8, 1/16, etc. Those numbers (or any multiple or combination thereof) can be represented precisely in floating-point format and can be added, subtracted and/or multiplied indefinitely without accumulating errors.
Decimal fractions cannot be represented precisely and so every arithmetic operation accumulates a small error (depending upon the floating-point format used and the value in question).

In this case, the floating-point format is that used by the underlying C99 (in which TinyScheme, Script-Fu, libgimp and GTK are all coded) which is IEEE-754:binary64 (see http://en.wikipedia.org/wiki/Double-pre ... int_format) and so errors are of the order e-15 or smaller. (In the first exercise above, after 1000 additions, we have accumulated a total error of order e-12. But the Script-Fu Console does not display that residual error when the base value is anything other than zero.)

------------------

I have not yet got to the bottom of quite what is going on with the GTK spinbuttons, but this inherent imprecision of decimal fractions in floating-point format is certainly one factor involved: each time you click on an up/down arrow on a GTK spinbutton, GTK adds/subtracts the specified step-value configured for the spinbutton to/from the current value retained by the spinbutton; if the step-value is not a precise binary fraction (such as 0.125 decimal), then errors will, necessarily, accumulate. (This does not, of course, happen when you enter a value manually or push the slider to either end-stop - hence the difference.) So, in this respect GTK is not at fault, nor are the Script-Fu plugin or libgimp ..it is just in the nature of floating-point arithmetic and I'm afraid it is the responsibility of the script-coder to make his/her script robust against such issues.
Where GTK may still be at fault is in the end-stop behaviour: if you use the up/down buttons to step all the way to either the lower or upper end of the allowed range, GTK should return the precise value of that limit ..which is precisely zero in the case of your test-zero.scm ..but it appears not to do so. That I am still investigating!

I'm always learning from you jontait2.

@jontait2 - I strongly disagree. I don't feel it is the responsibility of the coder to sanity check the stop position value of any widget provided by the Script-Fu plug-in (or for that matter, any other language), whether it be a left right slider, a vertical spin button, a circular rotating knob or whatever other kind of user interface you can imagine. If the stop position is zero in SF-ADJUSTMENT, then it should always return zero.. period ..end of story. If SF-ADJUSTMENT is not returning the correct stop value, then SF-ADJUSTMENT is broken and needs to be repaired.

If I were writing a procedure identical to SF_ADJUSTMENT, it would be my responsibility to provide the correct return values to the caller.