Ask for good ideas about handling floating point number!

[drbitboy]

this is to bump the low limit and high limit to my understanding, and then I can simply compare them with the given/measured value;

exactly.

 

[I_Automation]

As far as resolution for the decimal, that may not be appropriate for your application but I will interject it anyway:


When I have had to use Pi in a computation I started using different resolutions - 3.14, 3.1416.3.14159 and so on watching the result.


I found 3.1415926 gave a more usable number without going into further decimal points, and further deep values barely gave any difference for a machine operation by PLC.



Now if my PLC was controlling guidance for the mothership to get me back home I would go more precise, but since it looks like I'm stuck on this planet 7 decimal places is fine.


EDIT: Just found this to archive if that mothership ever gets here. 100 places might be accurate enough, but the entire million will be nice to know

 

[ndzied1]

If you are sticking in fixed point math pi can be achieved quite well using the fraction
355/113

Multiply by 355, then divide by 113.
Or with 1 implied decimal place multiply by 3550 and divide by 1130.

 

[iuhytvYUTCU]

To drbitboy...

I tested MUL and then DIV using 16777215/16777216 and 8388607/8388608, and the more complicated one you wrote yesterday, I think results of them were good, just that I saw the calculated limits are not always the same numbers across these three methods. Do you know why?

For example, 0.016+0.001 is 0.017, which is true for a direct ADD instruction, but after MUL & DIV 16777215(6) it became 0.01700003, and it may be another number for 8388607(8) (if not 0.016 & 0.001 combination), and I can see the latter number may be a little wider in range.
At the same time BUMP AOI would (may) give another number apart from 0.01700003 as well.

Anyway, I decided to go with the 8388607(8) trick, if you would suggest I can do more test tomorrow, which is the last day I can access a PLC in the next few days upcoming.

 

[drbitboy]

any one of those that works should be fine; there is probably not more than one or two bits of difference between the various approaches.

All of those approaches are tweaking mantissa bits that correspond to the sixth or seventh decimal digit, or even the invisible eighth digit, so if your operators are entering only four or five digits it should be fine.

The BUMP AOI is probably best, as it deals with the problem directly where it resides i.e. in the bit domain, with no more bits added or subtracted than absolutely necessary.

8M/(8M-1) is probably the best compromise between minimal complexity and 100% reliability, although it may act a bit() more aggressively than needed. I think you made a good choice going with this.

16M/(16M-1) is the similar to 8M/(8M-1), but less aggressive; however in some cases the rounding may have it do nothing and cause reliability issues.
_

 

[iuhytvYUTCU]

Ok then, appreciate your help out along the way!

take care of the bits -- sounds real good