Yes, that's the point I made at the end of my rant:

But that doesn't alter the fact that, at any position between the end-stops, the floating-point value returned by GTK may not be quite what is displayed or what you were expecting. That's just an inevitable consequence of floating-point arithmetic and scripts need to be robust against such effects. The Script-Fu Extension can only cosset the coder so far..

Edit:
In fact you don't need to do 1000 floating-point operations to hit an error, just 3 will do:

Well, I guess I don't understand the point you are making, in terms of the caller having to sanity check any value returned from SF-ADJUSTMENT. When calling SF-ADJUSTMENT, the precision is specified. The caller should expect the stop point values (and any value in between) to be returned correctly, to the precision specified. I don't see a need for sanity checking of any of those return values, as you seemed to suggest.

Yes, I agree, in an ideal world, or if we were doing this from scratch, then, yes, what we would really like is for SF_ADJUSTMENT (or whatever) to only result in values precisely on the step-points at or between the specified end-stops according to the precision specified.
And, indeed, that could be done in the Script-Fu plugin.
But, as I pointed-out in one of my earlier posts, if we upgrade the GimpChat Script-Fu plugin to perform this sort of sanitizing, that's still going to leave a problem for anyone running legacy versions of Gimp or using the standard Script-Fu extension as supplied with Gimp from the official sources. If they try running a script which assumes that the values passed are pre-sanitized, they're going to hit the same old problems.

This sort of highly-cosseted pre-sanitizing could be made a long-term goal for the Script-Fu Extension in Gimp development ..but then does Script-Fu have a long-term future in Gimp? Only if it can be upgraded to handle GEGL ops with higher color depth. (And that's a whole different story!)

I think we can agree that in the case of the spinner, Script-Fu is broken. Whether it makes sense to address the issue in the Script-Fu plug-in, address the issue upstream or not even address it at all, is a matter for the GIMP devs to decide. I certainly never suggested, nor do I think, including a fix in the scrolling Script-Fu modification would be appropriate.

Those who use legacy versions of GIMP that contain bugs have deal with those bugs. As script/plug-in coders, we can usually come up with workarounds for bugs, hopefully workarounds that don't break when the bug is finally fixed. Perhaps you were simply conflating workarounds for bugs with sanity checking, which from my perspective, are two totally different things.

Problem 1: saying "Script-Fu is broken" assumes that it was the intention that SF-ADJUSTMENT would only result in values precisely on step-points ..and it doesn't actually say that anywhere in the Gimp docs AFAIK.

Problem 2: if you report this as a bug, the Gimp devs are likely to say it's a GTK problem - ie. the GTK spinbutton should only return values precisely on step-points ..and therein lies the problem with floating-point arithmetic: when you use the up/down arrows, the GTK spinbutton updates the value by repeatedly adding/subtracting the step-value to/from the current value - it is not clever enough to "normalize" the value onto step-points (and thus eliminate any accumulated arithmetic errors) and it would be quite a major change to introduce that functionality.

As for conflating bug-fixes with sanity-checking: - no, I am fully aware of the difference, but having spent more than 20 years in systems engineering, much of it on safety-critical systems which people's lives depend upon (literally), I am in the habit of making my software as robust as the proverbial brick out-house ..all input has to be validated, never take anything on trust ..there's nothing worse than a critical system being taken down or rendered useless by some silly little extraneous factor.

I'm arguing that, as a matter of robustness, scripts should check/sanitize the input supplied to them; you're arguing that the Script-Fu environment should take care of that sort of thing so the script coder doesn't have to worry.
But, as I said before, you can only cosset the coder so far, sooner only later the would-be script-coder is going to have to deal with the realities of floating point numbers and the unexpected results, eg:

I stand corrected. Clearly, we don't agree.

Problem1 - It's pretty obvious what the intention is with SF-ADJUSTMENT and it's also obvious that it's broken

Problem2 - Pure speculation as to how the GIMP devs would respond.

I'm of the opinion the spinner is broken. Your opinion may differ.

Can you provide an example of the "Sanity Checking" you would perform on the following?

SF-ADJUSTMENT _"Value" '(1 0 40 .1 1 1 0)

Perhaps a more fundamental question is whether Scheme/TinyScheme actually has an epsilon factor and, if so, what it is set to. For example, if epsilon were set at e-10, we would not see any of these anomalies.
Perhaps what we should really be addressing is this:

What you've posted is a workaround for a known bug. What if the procedure (SF-ADJUSTMENT) returned a negative value or value greater than 40 or another data type or any number of other anomalies that could possibly be returned. That is what I consider validity checking and it's not necessary here.

My point is that those kinds of checks should be handled inside the procedure (SF-ADJUSTMENT). The coder of SF-ADJUSTMENT should be ensuring the return values are correct. If there is a bug in the procedure that's causing an incorrect value to be returned, it would be discovered by testing, which is how this bug was found. The solution is not to sanity check all possible return values for every function/procedure you call. The solution is to fix the procedure containing the bug. In the interim, a workaround might be necessary.

Btw- The variable myScriptFooStepSize would be undefined when used that way in SF-ADJUSTMENT

Ah!
We're talking slightly at cross-purposes here. I'm talking about sanitizing input values - that is, making them fit for use; you're talking about sanity checking. And yes, a full sanitizing would require range-checking as well, but probably not data type - the values are just supplied to the TinyScheme interpreter as ASCII strings and the interpreter treats all numerical values as floats until and unless it is told otherwise.

BTW. There is no procedure "(SF-ADJUSTMENT)" ..."SF-ADJUSTMENT" is an enum literal to select a spinbutton or slider+spinbutton widget. The setup is done in file script-fu-interface.c function script_fu_interface() and any sanitizing would most probably be done in procedure script_fu_ok() in that same module.

As I alluded to above, I'm beginning to think this is actually a much bigger (and more general) problem than just getting values from spinboxes. You can't even multiply 0.1 by 3 and get a reliable result!
I cannot find any reference to epsilon or floating-point error levels in Scheme. How does Python do it?
As far as I can remember Intel processors do have a configurable floating-point error level but is it actually used and if so how?

Well I'm going to possibly muddy the waters further:

From the attached Python script (registers next to the script-fu script in the menus) and consistent across GIMP 2.6.7 and 2.8.14 on Windows 8.1


Edit: I had to try something else - changing the increment size to 0.01:


And adjustment01 (the 0.01 increment) passes the equals zero test.

Kevin

@jontait2 - Yes. I'm well aware of how the Script-Fu interface works.

Perhaps I was a bit inarticulate in my verbiage. I was referring to any generalized "procedure" and only used SF-ADJUSTMENT in reference to our previous discussion (generically referred to as a procedure because it accepts arguments and returns values). Also, a "procedure" can be defined as a section of a program that performs a specific task, somewhat equivalent to a "routine", so in that respect, procedure is the correct terminology.

Anyway, I do agree that one must be careful when comparing floating point calculations. We are certainly seeing some inconsistencies here. When dealing with raw floating point calculations, I tend to round to a whatever precision I need.

> (= (round-decimal 1 (* 0.1 3)) 0.3)
#t

What I don't understand is why Ofnuts found he couldn't reproduce the problem in Python.

According to this: https://docs.python.org/2/tutorial/floatingpoint.html it should have the same problem.

Did you miss Kevin's post?

Ah, right!
I missed that post completely somehow!

Okay, it's pretty clear now that neither Script-Fu nor Python have any generalized means of handling error levels in floating point arithmetic - there is no programmer-defined or system-wide software-epsilon, so the script coder is always going to be at the mercy of the machine-epsilon.

I'm not going to argue this with you any further Tux, if you want to report it as a bug then go ahead and I'll give any help/info you need.

I would not say that "the precision is specified", only the the number of decimal places in the displayed result specified.

While it would be nice if "the precision" were specified, this would introduce some problems with regard to complying with human interface guidelines; one being that the slider box, when dragged, would no longer follow the motion of the mouse pointer. Furthermore, such a change would pose a rather significant change to how GIMP has behaved for nearly two decades.

Though I think this is ultimately a problem with the GTK adjustment widget, I doubt the GTK devs would give much serious consideration to addressing it. Firstly, GIMP is using version 2 of GTK+, whereas GTK3+ was released over four years ago. While I myself think GTK3+ is flawed in many ways and thrilled that GIMP is staying with GTK2+ for now (at least for GIMP 2.10), I would understand any reluctance by the GTK+ devs to addressing a problem that has never been raised as a significant issue, may only affect "outdated" code, may only be properly fixed by redesigning the widget's API, and could arguably be called a design limitation and not a bug.

My guess is that they would claim that the widget behaves as expected (given the constraints of floating point arithmetic) and that you are free to implement your own widget that behaves differently.


Currently there is no special treatment of the SF-ADJUSTMENT return values; they are treated just like any other parameter of the PDB_FLOAT type (which is a gdouble). From what I can tell, resolving this in the Script-fu plug-in would be quite messy -- trapping such parameters and then assuming that a certain precision would be sufficient for the coder's purposes.

My recommendation would be to address this issue within the script, because only script writer will know what problems need to be avoided. For example, if the only concern is about testing if x is "0" then the following should suffice:

(if (zero? (truncate (* x 1e15)))

If the result is supposed to fall upon precise intervals then the returned value should be rounded to the nearest of those possible intervals. I knew that this was something that had to be done for slider inputs, I just never realized that it applied to spinners as well.

Nonetheless, I shouldn't want to stifle a discussion of potential solutions, I just wouldn't get my hopes up.

You make some interesting points, Saul. Perhaps the precision is for display purposes only.

Nevertheless, my bottom line is that when I set the min value to be zero and use the spinner/slider or whatever to move to zero, and the result is not zero, I'd call that a bug. In that case, I don't think the return value should be anything other than zero, no matter whether it's an integer or float. Surely, you would agree that's a bug.

Maybe I have a new info, I'm not sure whether this has been said explicitely before, there are so many infos here that I get somehow confused, but it looks to be new to me and -maybe- explains also why GnuTux sometimes (rarely) gets a 0 (obviously I talk ONLY about the spinner).
By making many many tests with the spinner I noticed that:
1-if I hold the cursor on the arrow down until 0.0 (which was my usual way of doing it) I get a perfect 0
2-if I go down step by step (0.9,0.8,0.7 until 0.0; pressing OK ONLY when 0.0) I get that strange value shown here many times (1.3877....e-16)
GnuTux (and any other people willing to continue testing), you may try to do a similar test.
Beware that sometimes (at least in my case with my mouse, after having stressed it) the mouse seems to be unable to hold perfectly down, so the script behaves like in case 2. I notice that because I see for a very little while a 0.x intermediate value before reaching 0.0.
Another info is that it seems the "hold-down-to-zero" technique works (i.e. produces a perfect 0) also after having performed a first step down to 0.9, never (to me) with any other initial value less than 0.9.
Maybe Wallace too could perform this test, because maybe he too like me is used to "hold-down" the spinner up to 0.0. And this could explains his zeroes

That's a good find dinasset

I've done a further experiment based on a theory about that.

If I change the increment to 0.2 I get a different but repeatable non-zero value, but If I make the increment .200001 then I get zero - probably because the last step down will take the float value past zero and it gets coerced to zero.

My theory is that in the "button held down" state the float value goes past zero before the down button is disabled, thus forcing it to be coerced to zero.

This must mean that the spin-button widget is rounding the value to determine if the limit has been reached.

Kevin

thanks Kevin
what surprised me is that it "seems" that the parameters window is "processed" immediately, "interactively", even w/o clicking OK
so that the value is internally changed following each step
is it "normal" for all scripts?