Host Engineering Forum
General Category => Do-more CPUs and Do-more Designer Software => Topic started by: Bolt on July 29, 2021, 06:46:31 PM
-
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.
-
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.
-
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
-
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.
-
Isn?t this just MATH using Reals vs Integer?
-
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.
-
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.
-
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? :P
-
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)!
-
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.
-
Could you post your MATH instruction expression (copy/paste)?
-
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? :P
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.
-
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? :P
Yeah...um. Sorry.
Man, the jokes are hard to pick up on here today!
-
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.
-
Are you sure you can't just add a little code to allow us to cast R's to a R:DP? :P
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.
I know, you should come out with a MATH co-processor POM!
-
It appears that on the first couple of angles you are multiplying R11+R12 by 2 but also dividing by 2? Definitely losing 1 bit of significance there.
-
It appears that on the first couple of angles you are multiplying R11+R12 by 2 but also dividing by 2? Definitely losing 1 bit of significance there.
Yep, tunnel vision. The formula calls for twice the mean angle, which would be the same as summing the two angles. But, no change in resolution for me. Either way, I'm still many bits away from having the resolution needed for this prospective project. Thanks!