Hello folks,

as the title implies, I'm asking if there is a definitive answer to the problem.

I've already read these links:

https://techsupport.osisoft.com/Troubleshooting/KB/1172OSI8

https://pisquare.osisoft.com/thread/11718

But I can't find a definitive answer.

My example case is this.

I'm extracting data from a Single (float32) PI point and I'm figuring out what is the most correct value out of it.

The values are the result of this calculation: "TimeMethod=NotSupported;TimeRangeMethod=Total;RateConversion=hour" and when "ByDay" is specified: "TimeMethod=NotSupported;TimeRangeMethod=Total;RateConversion=day"

1 | SingleToDouble(A) | 257.78872680664062 |

2 | Double | 257.78872373090849 |

Single(A) | 257.788727 | |

SingleByDay | 10.7411966 | |

SingleByDayX24 | 257.788727 | |

3 | SingleByDayX24ToDouble | 257.78871917724609 |

My C# program treats everything as Double and I used PI System Explorer 2014 R2 SP1 to make this example.

As you can see, I'm referring to the green highlighted values, I can get up to 3 different values from the same PI Point and I would like to know which of the 3 values is the most correct: 1, 2 or 3.

IMHO, my instinct says the most correct value is (1).

My logic says (2) or (3).

(3) is different to (2) due to how AF is probably handling it's internal totaling calculation, I've no basis to say which one of the 2 is better.

Anyone have a clue?

Thanks

Hello Massimo,

Dealing with computers means transforming an analog value into a digital representation which is close to but not equal to the analog value. The digital representation will always be a little smaller or greater compared to the analog value. If it is greater or smaller is impossible to tell without knowing the exact analog value. The precision depends on the data type e.g. 7 digits with float32 and 15 digits with float64. By storing a float32 in a float64 data type, it will again be a bit smaller or greater than the float32 but you cannot predict if this new float64 representation is closer to or less close to the analog value than the float32.

So you don't get closer to the truth than with the float32 representation. When you look at the numbers you've posted, you will recognize that there are already differences in the 6. decimal place. Based on what I am seeing, I wouldn't want to offer more than 5 decimal places: 257.78872