Precise MATH Instructions

[Bolt]

I'm trying to do some calculations on a BRX, and am seeing about 8% error vs Excel.  When I simplify the numbers (in Excel and BRX), I get about 1/2% error, so it seems to be related to reals and rounding and what not.  Are there general rules of thumb to squeeze more precise math out of the MATH instructions?  This instruction contains SQRT and COS instructions.

[BobO]

Probably a single precision vs double precision issue. There are no simple rules, just an understanding of how each operation is adding error, and structuring the operations to minimize it.

[ADC Product Engineer]

Also understanding promotion/demotion is a pretty big deal.

2 * 3.5 might not be the same as 2.0 * 3.5

The MATH help explains it better than I can. Topic: DMD0085

[BobO]

Also understanding promotion/demotion is a pretty big deal.

2 * 3.5 might not be the same as 2.0 * 3.5

The MATH help explains it better than I can. Topic: DMD0085

Absolutely correct, although that example isn't the best. A better example would be 7/2 + 3.0 = 6.0, whereas 7/2.0 + 3 = 6.5. Get the order of those operations wrong and your results can get very skewed. Excel uses double precision float everywhere I'm sure, and generally those issues disappear. While I would love to use double everywhere in the PLC, it simply isn't viable with that hardware.

[Garyhlucas]

Isn?t this just MATH using Reals vs Integer?

[franji1]

Isn?t this just MATH using Reals vs Integer?

Yes.  Integer math is precise (assuming you don't overflow +/- 2billion)

Real math is NOT precise (e.g. you can't represent 1.0/3.0 precisely using IEEE floating point - it's just an approximation), hence complex expression errors can get "relatively" large, depending upon what you are doing.  32 bit (single precision) IEEE has 24 bits of precision, but double precision floating point has 53 bits, even more than 32 bit integer.

[BobO]

Isn?t this just MATH using Reals vs Integer?

In the OPs Excel vs the PLC case it can easily be single precision vs double precision float. There are a large number of ways error can creep into math.

[Bolt]

Also understanding promotion/demotion is a pretty big deal.

2 * 3.5 might not be the same as 2.0 * 3.5

The MATH help explains it better than I can. Topic: DMD0085

Yep, I'm aware of the implications of integer math, and the TOREAL/2.0 type solutions.

Isn?t this just MATH using Reals vs Integer?

In the OPs Excel vs the PLC case it can easily be single precision vs double precision float. There are a large number of ways error can creep into math.

Yes, I'm afraid that's what it boils down to is the lack of double precision.

Also understanding promotion/demotion is a pretty big deal.

2 * 3.5 might not be the same as 2.0 * 3.5

The MATH help explains it better than I can. Topic: DMD0085

Absolutely correct, although that example isn't the best. A better example would be 7/2 + 3.0 = 6.0, whereas 7/2.0 + 3 = 6.5. Get the order of those operations wrong and your results can get very skewed. Excel uses double precision float everywhere I'm sure, and generally those issues disappear. While I would love to use double everywhere in the PLC, it simply isn't viable with that hardware.

Are you sure you can't just add a little code to allow us to cast R's to a R:DP?

[Controls Guy]

Excel uses double precision float everywhere I'm sure

Don't be too quick.   Maybe the BRX is actually correct, and his PC has the Approxium ((c) Intel)!

[Bolt]

Excel uses double precision float everywhere I'm sure

Don't be too quick.   Maybe the BRX is actually correct, and his PC has the Approxium ((c) Intel)!

Nope. I've also checked it against online formulas to figure all the math out in the first place.

[franji1]

Could you post your MATH instruction expression (copy/paste)?

[Controls Guy]

Nope. I've also checked it against online formulas to figure all the math out in the first place.

I was just kidding.

[BobO]

Are you sure you can't just add a little code to allow us to cast R's to a R:DP?

Yeah...um. Sorry.

I actually fought with similar issues while developing the motion functions. Single precision wasn't accurate enough in a few of the axis calculations so I had to selectively add double. It was a little tricky getting the balance of accuracy and performance.

[Bolt]

Nope. I've also checked it against online formulas to figure all the math out in the first place.

I was just kidding.

Are you sure you can't just add a little code to allow us to cast R's to a R:DP?

Yeah...um. Sorry.

Man, the jokes are hard to pick up on here today!

[Bolt]

Could you post your MATH instruction expression (copy/paste)?

You asked for it!

SQRT(((((111.1321 - (0.56605 * COS(2 * ((R11 + R12) / 2)))) + (0.0012 * COS(2 * ((R11 + R12) / 2)))) * (R11 - R12)) ** 2) + (((((111.4151 * COS((R11 + R12) / 2)) - (0.09455 * COS(3 * ((R11 + R12) / 2)))) + (0.00012 * COS(5 * ((R11 + R12) / 2)))) * (R13 - R14)) ** 2))

I didn't fully expect it to "work", I was testing the capabilities, to see if a PLC would be suitable for the application.  Seems I might be striking out.