Sorry, Kevin, nice theory but it doesn't work like that. I've been right thru the GTK spinbutton code and all the range-limiting, stepping, etc is done with double-floats and no rounding in sight.

I think the reason you're getting different results with step-interval 0.2 and different again with 0.200001 is simply a matter of the way the floating-point errors accumulate.
0.1 in binary is the infinitely-repeating sequence 0.00011001100...
So, in IEEE-754 binary64 which uses a 53-bit fractional part, the nearest approximation is:
0.00011001100110011001100110011001100110011001100110011
And 0.2 is the same pattern shifted left one place:
0.00110011001100110011001100110011001100110011001100110
These will accumulate tiny errors from the least-significant end in rather different patterns.
But the value 0.200001 is a completely different bit pattern (unrelated to either the above) and so will accumulate errors in a different way again.

@Dinasset
I think that's just the GTK spinbutton widget being updated "interactively" - the script itself will not be executed until and unless you hit the OK button.

Thanks Jonathan!
thus, if the "hold-on" is executed appropriately, GTK updates only one time, from initial 1.0 to final 0.0 and the result looks OK

...and it would be possible to have a GTK spinbutton which "waits"? thus reacting only to when the script enters again thru the OK of the user?
maybe a silly question again....

No, when you first press an up/down button, GTK increments or decrements the value immediately but also starts a timer for 0.5 second. If the button is still pressed at the end of that 0.5 second, GTK will then start auto-incrementing/decrementing the value every 0.05 second until you release the button.
Every time the value is updated, it is passed to the Script-Fu Extension plugin, which stores the new value in a local data structure for the script in question..


Sorry Diego, I don't know what you mean by this. The script itself does not do anything until and unless you press "OK" on the dialog. In doesn't have any opportunity to do anything. The entire dialog is executed by the Script-Fu Extension plugin on behalf of the script, using the information in the registration block (ie. the SF_xxx parameters)

I will agree that it is a bug that the returned value is not "0" when the display is "0" AND the spin down button is grayed out. That is to say, when the value is 1e-16 or somesuch, it may not be a bug that "0" is displayed yet one should still be allowed to spin it down to "0" -- this regardless of whatever step size is chosen or precision used for display.

my turn not to understand, and I do not mean that I don't understand what you say, but I don't understand why -by the "hold-on" technique- the resulting value is shown precise 0 if starting from an initial value >= 0.9, because, following your explanation:
- as soon as I press the down button GTK decrements the value immediately (? thus to 0.9 or 1.0 or...whatever initial value ?)
- then (because the hold-on certainly stays for more than 0.5 seconds) the value is updated again (when input is 0.0) and the displayed value is precise 0 (OK)
But the same should occur if I use this technique starting from any value, also below 0.9, if I hold the down botton for more than 0.5 seconds, the parameter shows at the end 0.0, the new update takes this 0.0 but the msg displays that "strange" value; why?

I think I've found the spin-button limitation is 1e-10:

This displays the dialog with the spin down button disabled, and because the increment is also 1e-10 it never gets enabled by single presses of the up button.

Kevin

Yes, I've come across this before. This document says that you can configure the spinbutton to display up to 20 decimal places: http://www.pygtk.org/pygtk2reference/cl ... set-digits

But thats just the display ..internally the spinbox only works to 10 decimal digits accuracy.
in file gtkspinbutton.c:

I noticed this last night, as well. Anything above 10 digits, the spinner becomes a dunsil (a part without a useful purpose). I suppose once the precision gets high enough, errors that creep in make the results pretty much useless anyway.

GTK spinbutton fails to "snap" to limits reported as a bug:

https://bugzilla.gnome.org/show_bug.cgi?id=748392

One of the best bug reports I've ever read. Very well written.