A script i’m attempting to write isn’t working as intended, i’ve condensed the problem into the coding below
----------------

(define range (make-vector 4))

(vector-set! range 0 '(255 0 0))
(vector-set! range 1 '(0 255 0))
(vector-set! range 2 '(0 0 255))
(vector-set! range 3 '(128 128 128))

(define vary 2)

; (set! vary 1.3333)
; (set! vary (round vary))

(gimp-context-set-foreground (vector-ref range vary))

----------------
As written the script works and the foreground colour is set to Blue

If the first semicolon is deleted, vary is set to a non integer and the script fails (as expected)

If the second semicolon is removed i expected the script to work, but it fails with the error

Error: vector-ref: argument 2 must be: non-negative integer

Where am i going wrong ?, any thoughts

Your condensed version appears to behave correctly.



Can you provide the "uncondensed" version? Perhaps the problem lies elsewhere.

maybe round does not return an "exact" integer value (an exact integer is for instance 3 while 3.0 is not) in the current scheme implementation;
try to use the procedure inexact->exact : (set! vary (inexact->exact (round vary))) when you are in doubt

PS: you may also use the function trunc to get an exact integer

Ah, now there is a difference, it works for you but not for me, after running through the SFC i get the error below

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

> (define range (make-vector 4))

(vector-set! range 0 '(255 0 0))
(vector-set! range 1 '(0 255 0))
(vector-set! range 2 '(0 0 255))
(vector-set! range 3 '(128 128 128))

(define vary 2)
range#( (255 0 0) () () () )#( (255 0 0) (0 255 0) () () )#( (255 0 0) (0 255 0) (0 0 255) () )#( (255 0 0) (0 255 0) (0 0 255) (128 128 128) )vary
> (set! vary 1.3333)
1.3333
> (set! vary (round vary))
1
> (gimp-context-set-foreground (vector-ref range vary))
Error: vector-ref: argument 2 must be: non-negative integer

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



I could provide the uncondensed version but it’s a bit large as the vector range is from

(vector-set! range 0 '(0 0 0))
(vector-set! range 1 '(1 1 1))

Through to

(vector-set! range 254 '(254 254 254))
(vector-set! range 255 '(255 255 255))

Quite a long list ?, do i just copy and paste it in

Thanks, that looks very interesting, will try it out

ps i've tried round, floor, ceiling and truncate but none worked

In Script-fu's implementation of Scheme, round and truncate both produce exact numbers (in TinyScheme, integers -- and only integers -- are exact unless manually coerced to inexact). This is not necessarily true of other implementations; for example in Guile, round and truncate can produce inexact integers while non-integer rational numbers may be exact.

You are absolutely correct; the safe bet is to include the coercion, especially if your code is to run on different Scheme implementations.

Thanks dinasset and saulgoode

(set! vary (inexact->exact (round vary)))

has solved the problem, a good lesson learned

Thanks again

Interesting. On my system, round returns an exact integer:



Which version of GIMP are you using? (I have 2.8.14) And what locale do you have set? (I am using en_US)

Saul,
the problem IMO is as follows:
- the value returned from round is considered an exact integer but is interpreted in an incorrect manner by some filters.
Because round returns a value made by an integer PLUS a dot PLUS one (or maybe more) zero(es) that value is interpreted as an integer which includes the zero(es)
I made an experiment with the filter lew-engrave
- passing the result of a division (let's say 9/2) for the value line width using the scheme function quotient it gets the value 4 (OK)
- passing the result of the same division using the scheme function trunc it again gets the value 4 and works appropriately
- passing the result of the same division using the scheme function round it gets 4.0 which is accepted but interpreted as 40! hence the filter works badly

If you want, you can make your own experiment using the attached code

I’m using GIMP (2.6.11)

> (exact? (round 1.3333))
#f

Its interesting if a little troubling

Sorry don’t know what locale is set to or where to find this info

I am wondering what you are seeing to indicate that the line width is interpreted as "40". If this is true, there is likely a bug in the engrave script. I have not delved into the script to find what might be wrong, but I do notice a misapprehension in the author's description of the SF-ADJUSTMENT statement.


The highlighted parameter has nothing to do with determining whether the result is an integer or a float, it is the number of fractional digits that should appear in the displayed number (e.g., 0="1", 1="1.0", 2="1.00", 3="1.000"). Regardless of that parameter's value, the number passed to the script is the fully accurate floating point value (it is never an integer).

Try the following code to see what I am struggling to convey (unless you already know all this):

Even though the displayed number is an integer -- either "0" or "1" depending upon which half of the slider you're on -- the value passed to the script is a full-precision floating point number ("0.3124142857", for example). If you change the SF-ADJUSTMENT configuration to '(0 0 1 1 1 4 0) then the displayed value will be shown accurate to a ten thousandth of a unit (e.g., "0.3124") but the script will still receive the fully accurate floating point value. It is up to the script to convert such arguments to their intended precision. If the script requires an integer then it should round or truncate the supplied floating point number.

Hi Saul,
you write "I am wondering what you are seeing to indicate that the line width is interpreted as "40""
It was only a guess (wrong) after having seen the different results from my test script.
Here they are:
image obtained by using "quotient" (the values are in all cases 9 as dividend and 2 as divisor)

image obtained by using "trunc"

image obtained by using "round"


you may easily understand the reason of my guess (wrong)

but what is definitely true for me is:
while quotient and trunc return a pure integer without any appended fractional value, i.e. simply 4, round returns a value which is not a simple 4, maybe a float value, IDK

you are right when saying that the filter should take care of what it expects, but from a coder point of view who makes use of an existing filter I'm right in preferring to use trunc and not round, for safety... at least as long as the behaviours will not be equalized

To be honest, I don't recall ever using 'round' -- you will typically find expressions such as (truncate (+ x 0.5)) in my code instead. The problem with 'round' is that it follows the IEEE standard of rounding any midpoints to the nearest even ( 1.5 rounds to 2, while 2.5 rounds to ... 2). This is done with the intention of statistically averaging out the times you round up with the times you round down. This may be useful when doing accounting and such, but for most graphical operations I want consistency in the result -- if I have a set of points that I want to scale or offset, I do not want the calculated values for the end coordinates dependent upon whether the coordinates happen to be odd or even.

So in my opinion, your preference of avoiding 'round' is a wise one. If there is a problem with using 'round', the reason I've never encountered it is because I don't use the function.

P.S. As a minor issue, 'trunc' is deprecated in Script-fu (and non-existent in most Scheme implementations). You should probably switch to its replacement, 'truncate'.

thanks Saul.
But, in any case, don't you think that "round" should return a "pure" integer value?
By "pure" I mean having no decimals at all, not having decimals set to 0.
If even or odd doesn't matter (at the moment...) to me, but I don't understand why does "round" return a value which is not a pure integer (1, 2, 3, 4, ....)
What is your opinion on that?