J
For some utility streams that may have totalizers that run without resetting for a year or more, the sum can get very large while the increment is small. To avoid problems with machine accuracy (for what value of j does your machine give you 1.0 + 1.0E-j = 1.0?), I split the total into an integer (SUMi) and floating point (SUMf) part as in the following pseudocode. Here, Trigger is an integer.
SUMf = raw*scale*dt + SUMf
IF SUMf > FLOAT(Trigger) THEN
SUMi = SUMi + Trigger
SUMf = SUMf – FLOAT(Trigger)
ENDIF
For display or recording, the sum is SUMi + SUMf. Sometimes it’s necessary/convenient to maintain SUMi in accumulators. Other approaches are possible… the idea here is to avoid roundoff error associated with adding large and small floats a billion times over the course of a year, especially towards the end of the year.
SUMf = raw*scale*dt + SUMf
IF SUMf > FLOAT(Trigger) THEN
SUMi = SUMi + Trigger
SUMf = SUMf – FLOAT(Trigger)
ENDIF
For display or recording, the sum is SUMi + SUMf. Sometimes it’s necessary/convenient to maintain SUMi in accumulators. Other approaches are possible… the idea here is to avoid roundoff error associated with adding large and small floats a billion times over the course of a year, especially towards the end of the year.