using a counter

[gravy]

I've used a variable as a counter in a number of macros to control the number of times things are done, in what order, etc.. Like in the logic below which does a macro at different places in X, the first at zero, the second at 6.5, third 16., fourth 22.5. (These are vise stops)


N1
G65 P20
#101=[#101+1.] (increment counter)
IF[#101EQ1.]THEN[#102=6.5]
IF[#101EQ2.]THEN[#102=16.]
IF[#101EQ3.]THEN[#102=22.5]
G52 X#102
GOTO1

What I'm wondering is if this is something where the limitations of binary arithmetic will eventually burn me. If I'm doing a bunch of math in a macro it seems to be an issue but just doing a counter seems to work. Am I just lucky?

[Eurisko]

Checking for equalities with floating point numbers can be a little tricky. However, your counters are essentially integers, and that's a different story.

As long as the counter is properly initialized, and is checked for a terminal value at each iteration, you should be fine.

I would also use a default (harmless) value for #102. If none of the comparisons succeed, what is the value of #102 ?

[gravy]

Originally Posted by Eurisko Checking for equalities with floating point numbers can be a little tricky. However, your counters are essentially integers, and that's a different story. As long as the counter is properly initialized, and is checked for a terminal value at each iteration, you should be fine. I would also use a default (harmless) value for #102. If none of the comparisons succeed, what is the value of #102 ?

Quick questions on break here.

What do you mean "terminal value"? So integers pretty much always succeed?

Thanks for your help!

[Eurisko]

Originally Posted by gravy ...What do you mean "terminal value"?...

A terminal value would be the first invalid count that the routine sees.

If you're using 3 vise stops, the value of the counter can only be 1, 2 or 3.
If the counter increments to 4, your program has to recognize that and take the appropriate (terminating) action.

Originally Posted by gravy ...So integers pretty much always succeed? ...

It is still a floating-point representation of an integer. It is valid only if the "integer" doesn't exceed the physical limits of the control. For example, If the control is capable of 12 significant digits, that would limit the size of the integer. You can calculate incredibly large or small numbers, but only the significant digits are stored. 3.02178362898 E +200 would truncate a LOT of digits.

The problem with comparing floating point numbers is due to these limits of precision (and rounding). Hope this makes sense.

[gravy]

Originally Posted by Eurisko A terminal value would be the first invalid count that the routine sees. If you're using 3 vise stops, the value of the counter can only be 1, 2 or 3. If the counter increments to 4, your program has to recognize that and take the appropriate (terminating) action. It is still a floating-point representation of an integer. It is valid only if the "integer" doesn't exceed the physical limits of the control. For example, If the control is capable of 12 significant digits, that would limit the size of the integer. You can calculate incredibly large or small numbers, but only the significant digits are stored. 3.02178362898 E +200 would truncate a LOT of digits. The problem with comparing floating point numbers is due to these limits of precision (and rounding). Hope this makes sense.

I just thought of this. If it is really a problem I could do this

#101=[#101+.1]
#101=FIX[#101]

before the IF THEN statements to first make the numbers greater than the target integer and then truncate them.

That's a lot of trouble. Is it really necessary do you think?

[Eurisko]

Originally Posted by gravy I just thought of this. If it is really a problem I could do this #101=[#101+.1] #101=FIX[#101] before the IF THEN statements to first make the numbers greater than the target integer and then truncate them. That's a lot of trouble. Is it really necessary do you think?

Don't do it. Your counters will work fine just by incrementing them. The control will have no problem adding 1 to a small integer. It will have no problem comparing 2 small integers. Precision won't be a problem.

[stevo1]

Gravy,
What Eurisko is referring to on "if the comparisons don’t succeed" is how do you end the program. If you come out of your program 20 sub on vise #3 this means that #101=3. Now when it runs through your calculations it get’s set #101=4. You have no X#102 value or equation programmed for #101 if it’s set to 4 so you would run the same vise(3) over and over again.

I would stick a calculation in the program so when your 3 vises are complete then the program ends.

N1
G65 P20
#101=[#101+1.] (increment counter)
IF[#101EQ1.]THEN[#102=6.5]
IF[#101EQ2.]THEN[#102=16.]
IF[#101EQ3.]THEN[#102=22.5]
IF[#101GT3.]GOTO2
G52 X#102
GOTO1
N2M30

Ahhhh the joys of floating point math. This just burned me about 6 months ago. I write a lot of extensive macros and never had a problem until I came to this new place. I was writing a C-bore macro and the data would show equal to each other when viewing the variable settings but it would not jump out of the loop of the macro. An example of what Eurisko is referring to is:
I was using #2 as a counter but this counter was adding the pick. And at the end the last pick could be any amount past the decimal 0.xxxxxxxxxx. I set #1 as a hard number for #2 to be equal to and end.

#1=2.
N1
IF[#2GE#1]GOTO100
…
…
#2=#2+.039
GOTO1
N100M30

My problem was that even though #2 would read 2. It was actually 1.999999999999999 so it never jumped out of the loop until the next pass. So the fix was to add a rounding function in the program. This would round the 1.99xxx number to the placement that I wanted which was .xxxx

#25=10000(ROUNDING)
#1=2.
N1
IF[ROUND[[#2*#25]/#25]GE#1]GOTO100
…
…
#2=#2+.039
GOTO1
N100M30

(these numbers are just examples they don’t actually add up to the 1.9)

Stevo