double math error in macro

[merrick]

I'm writing a macro that probes for the center of an square/circle. Part of the macro is finding Y0 (min) and Y1(max) so it can get to the exact center Yc = (Y0 + Y1)/2. At the end of the macro, it sets zero the X-Y coordinate at (Xc,Yc).

If I run this macro repeatedly in one place (a few times), I will get to a case when Y0 = negative Y1 (according to the status output because it already at center) but the Yc = (Y0+Y1)/2 will be something very small/very huge, so the machine would crash on the next move.

My guess is that the result from (Y0+Y1) isn't quite zero but something extremely small. The math error thus is due to number overflow and a pretty dangerous one (sending my cnc crashing badly).

Attached is the macro. I'll post the screen shot of the status output later.

[merrick]

Attached is the output screen when it happen

[dezsoe]

The result will not be huge: there is a E-16 at the end, that's really small. The issue with double math is known, it comes from the technique of calculating with doubles. Round your results to 5 or 6 decimals, it's far enough. And use #5061 to #5066 to get more precise G31 results.

[merrick]

I'm using 5061 and 5062 as you said.

The problem is the calculation ends up with something really small/really big and the result using in a exec.Code("G00 ...) will crash the machine. When the picture was taken, the machine has already crashed into my -Y limit.

So if the number is really small, the bug is in how uccnc response to such a small # in the exec.Code function. This could happens in any macro/situation where caculation is involved, not just while probing.

I can, of course, round off the numbers in this case. However, rounding off all numbers before sending it to the exec.Code function is not realistic.

[cncdrive]

It is not a bug, but is comes from how double precision numbers are stored on computers. There is no such thing as infinite precision when it comes to floating point numbers. The possible size of this error depends on the representations / storage of the numbers.
The error is not very huge, but actually very small, it is in the size of E-16 which is actually 0.00000000000000022, which size of error I don't think will cause any real world problems.
If you think this error is still too much then you could calculate with Decimal variables instead of Doubles, then the Epsilon will be in the size of E-324 instead of the E-16 if I recall,
however I don't think that even a E-16 error is in the range where it could cause any problems.
The other solution is as Dezsoe adviced is to round your results to 5-6 or more decimal places when you divide or do math operations which could cause unprecision.

And yes, use the # vars to read the results instead of reading the DRO values, because reading the DROs will read the position of the stop point of the probing and not the probed coordinate and this can cause a size of error which can cause a real error size.

[merrick]

I went back and test the following code sniplet:

double Y=-2.22044604925031E-16;
exec.Code("G1 F25 Y" + Y);

After zeroing the Y DRO, the code move -2.2203 in the -Y direction. The bug is in the code becoming exec.Code("G1 F25 Y -2.22044604925031E-16") and uccnc just ignores everything after the 4th decimal place without proper conversion.

If the bug isn't fixed, anytime the calculation becomes so small, the exec.Code function will fail when used in this case.

[cncdrive]

And this issue is as said not in the UCCNC, but it comes from how floating point computation works.
The UCCNC using the .NET framework built in Math routines, so when you do math you calling routines written by Microsoft and not by us, so any bugs you may find there are bugs in Windows, however I did not seen a single one in the like 10 years since .NET exists and since I'm programming in .NET, so that you will find any math bugs is not likely...

[merrick]

Consider this:

exec.Code("G1 F25 Y -2.22044604925031E-16");

This code should not move the machine at all but UCCNC moves it -2.2203 units. Isn't that a bug? No calculation involves here. Perhaps I should titled the post as bug in UCCNC in dealing with very small number?

There are two facts one should consider:

a. Some calculations will end up being very small as in this case
b. If such calculation is used in the exec.Code function, the uccnc software will behave abnormally

[ger21]

It's not a bug. You can't specify coordinates using exponents. The E-16 is unknown and ignored
You need to change the format of the number to not use exponents.

[merrick]

It's not a bug. You can't specify coordinates using exponents. The E-16 is unknown and ignored
You need to change the format of the number to not use exponents.

I did not write the exponent in there. The exponent comes from the exec.Code("G0 Y" + Y) where Y is very small. I'm just trying to point out that the software does not do proper conversion of number from string to double. If UCCNC disallows the use of exponent, perhaps the software should also avoid converting Y into exponent format.

As it stands now in UCCNC, one could only write exec.Code("G0 Y" + Y) or exec.Code("G0 Y" + Convert.ToString(Y)), and in either case, the result has exponent in it. The only work around is to to manually round up very thing to the 4th decimal place before feeding it to exec.Code function.