[rrd-users] Empty sections in AREA on graph, but values in database
Simon Hobson
linux at thehobsons.co.uk
Thu Aug 28 12:07:36 CEST 2014
Thomas Brinkmann <thomas.brinkmann at email.de> wrote:
> this is working :-)
Good news
> so this must really be a internal math and rounding issue.
I'm thinking that unless your graph has *exactly* one pixel per data point, then there is data manipulation going on. Say a pixel takes in a little over a data point - lets say 1.27 data points/pixel, and for simplicity, we'll say the start point is the same so only "one end" is subject to calculation.
Assume both data points contain exactly 1.0, the calculation would be :
x=(1/1.27) + ( (0.27*1)/1.27) or x=( 1 + (0.27*1) )/1.27
In practice, the start of the pixel probably doesn't line up with the start of the data point, so the calculation is more likely to be something like :
x=( (0.15*1) + 1 + (0.12*1) )/1.27
Since the maths is done with finite precision, you can now see why even feeding in a steady stream of "exactly 1.0", you might not get out exactly 1.00000000000000. More importantly, you might get out something which (after truncation/rounding) displays as 1.0000000 but which does not (internally) equate to 1.0
I recall (cough) years ago when first learning about computers and programming, the teacher showed the effects of limited precisions very simply. This was in the days of BASIC, and we were told to write a short loop to count from 0 to 1 in steps of 1/100 (or something like that). Of course we all did :
for a = 0 to 1 step 0.01
print a
next a
Needless to say, at some point we ended up with rounding errors and the final value was not 1 but typically something like 0.99999999. The simple reason being that decimal fractions (other than 0.5, 0.25, 0.125, and so on) don't have an *exact* representation in binary floating point. While iterating multiple times, these errors accumulate.
More information about the rrd-users
mailing list