Why me???

[dunbarx]

This snippet in a small test stack shows three ways to escape a repeat loop when the variable "endSpace" reaches 30:

Code: Select all

on mouseup
   put 29.9 into endSpace
   repeat until endSpace / 6 = 5
    --repeat until endSpace mod 6 = 0 
    --repeat until endSpace / 6 is an integer 
      add 0.1 to endSpace
   end repeat
   answer endSpace
end mouseup

All three fire properly. But if I place this inside a handler in another project, only the first line escapes the repeat. Even though endSpace attains the value of 30, the other two do not, and endSpace gets to 30.1 and beyond.

How could one stack work and another not???

Craig

[Klaus]

Hi Craig,

I never ever used "repeat until...", no idea why.
I always use an IF THEN condition to exit the loop if neccessary, maybe this will work for you:

Code: Select all

on mouseup
   put 29.9 into endSpace
   repeat 
   ## until endSpace / 6 = 5
    if endspace/6 = 5 then
       exit repeat
    end if
    --repeat until endSpace mod 6 = 0 
    --repeat until endSpace / 6 is an integer 
     add 0.1 to endSpace
   end repeat
   answer endSpace
end mouseup

Best

Klaus

[dunbarx]

Klaus.

Thanks for the reply. But no, changing the form of the repeat loop does not work. I had originally, with an arbitrary value in the variable "endSpace":

Code: Select all

....
repeat
   if endSpace mod 6 = 0 then exit repeat
   else add 0.1 to endSpace
end repeat

I need to take that variable and find the nearest larger even multiple of 6 into which it "fits".
This works in the small test stack I made, but not in the project I really need it to. There the loop continues right past a value that should force an exit from the loop. Something like this has never happened to me before.

Craig

[Klaus]

GREMLINS, I'm telling ya'!

[dunbarx]

So I tried this:

Code: Select all

put 29.9 into endSpace
repeat
   put endSpace mod 6 into temp -- I get a "0" here on pass # 2
   if temp = 0 then 
      exit repeat
   else
      add 0.1 to endSpace
   end if
end repeat

On the second pass, I get a "0" in temp. Just guess whether or not the loop exits.

Craig

[Cairoo]

I need to take that variable and find the nearest larger even multiple of 6 into which it "fits".

Hi Craig,

I'd also be stumped by the behavior you've described. However, there may be a better way to find the nearest larger even multiple of 6 into which it fits.

Here's a little function that may get you what you're looking for:

Code: Select all

function nearestMultiple pNumber, pMultiple
   put pNumber div pMultiple into temp
   if temp < (pNumber / pMultiple) then
      add 1 to temp
   end if
   return temp * pMultiple
end nearestMultiple

I hope that helps.

Gerrie

[dunbarx]

Cairoo.

Adorable and compact. Thanks.

My task was to find the best fit among a suite of options, increasing a certain value step by step until several other values were optimized. This had to do with fitting different parts into a thingie. I wanted to check on things at certain milestones, and finding a zero mod value would have done the trick. Have no idea why one stack works and another does not, with the same code.

I solved it, as usual, by rethinking the problem.

Craig

[paul@researchware.com]

I would recommend you add parenthesis to ensure the math is performed in the correct order. See below. Just extra insurance againt some sort of weird operator precedence behavior.

on mouseup
put 29.9 into endSpace
repeat until ((endSpace / 6) = 5)
--repeat until ((endSpace mod 6) = 0)
--repeat until ((endSpace / 6) is an integer)
add 0.1 to endSpace
end repeat
answer endSpace
end mouseup

[dunbarx]

Paul.

It tried that when I first encountered what seemed to be odd behavior. Nothing worked. So I took the handler intact and placed it in a new stack. All three cases fired properly. Back in the actual project, only one would, the explicit equality ("= 5"), but neither of the two others ("mod" and "is an integer").

Anyway, I just changed my methodology and moved on. Klaus thinks it is gremlins.

I hold the record, unmatched, for this sort of thing.

Craig

[Simon Knight]

Craig,

So how do I replicate the non working version? If I have understood your posts all three exits work when the stack only contains the code snip but place the same code in a more complex stack then two of the exits fail.

[Simon Knight]

I am unable to repeat the fault but I would guess that the maths operators introduce small errors which are normally rounded out, e.g. 30/6 = 5.0000000000000000000001 which is not equal to 5.

Does repeat until endpoint > than 29.9 work ?

Simon

[dunbarx]

Simon.

You would have to load the old version of the stack itself and try it. But I have already removed that portion of the handler in order to rework it.

I cannot imagine an "environmental" condition that would allow three versions of a section of code in a handler to work "properly" in one stack but only one of those versions in another. The code seems to be perfectly isolated from any possible "outside" influence. I also placed the test code sample, contained within a "mouseUp" handler as I posted here above, in a new button in the actual project and it ran fine.

So that snippet failed only inside a particular handler within that project (The code snippet that failed did not, of course, live in a "mouseUp" handler). The local variable "endSpace" appears nowhere else, and is created and gets its initial value from a calculation immediately preceding it.

I am sure it is me, but cannot see how.

Craig

[dunbarx]

Simon.

I bet you have a point here, in that a value may have a difference from "perfection' in the seventheenth decimal place. We all know that numbers on computers are not mathematically absolute, rather are machine representations with reasonable authenticity.

The value of the variable "endSpace" in the project version of that handler was not explicitly set, as in my posted test, but calculated via arithmetic.

But assuming there was such a hidden imperfection, that means that "mod" and "is an integer" failed muster due to that possible difference from a perfect integer, and "equals" did not.

Just the way computers work?

Craig

[Simon Knight]

Craig,

I'm sure that in the past I have run into similar issues when using the equality test. Why it works sometimes and not others is anyones guess but the greater or less than tests do seem reliable.

Simon

[dunbarx]

Simon.

Hmmm.

"Greater" or less than", for some reason, seems less susceptible to miss "the right answer". I am not sure why.

The spurious value of the seventeenth digit in any particular value can only be a number. And that number might be zero, but if not, is going to make the value itself something else. But that means that if you compare several times, the values of two identical arithmetic operations (9 / 3, for example) the results will vary, due to what number lives way down at the end?

Craig