[rrd-developers] a portable rrd format

Alex van den Bogaerdt alex at ergens.op.het.net
Thu Jun 21 09:06:27 CEST 2007


On Thu, Jun 21, 2007 at 08:14:41AM +0200, Tobias Oetiker wrote:

> > Is there really a need to convert NaNs to the local architecture or
> > will processors deal with different but correct types?
> > I'm not talking endianness here; I'm talking about 0x7ff400...
> > vs. 0x7ff800... vs 0x7ff00...1 and so on.
> 
> I don't know, but I would rather not bet on this ...

Ack.  Just wondering...

> the conversion does not have any measurable performance impact ...

gut feeling: there's always that pesky exception which you didn't
know about at the time you started, but is going to hunt you when
you're done making decisions, programming and releasing.

> > Is using floating point really the best option?  You are aware
> > that 10 times 0.1 is not 1, right?
> 
> I don't think I will be able to come up with a data format that is
> better suited to random numerical data than the brains who did
> IEEE 754 :-) ... the only challenge is to not do 'bad' math where
> we loose precision ...

I'm quite sure you won't provide a better solution to their problem.
Those people were certainly not stupid and did a good job.

What I am asking is if you are having the same problem and thus
require the same solution.

There are more ways to loose precision than just bad math.
Using floating point arithmetics is IMHO one of them.  In many
cases this is not a problem, but if you don't need the flexibility
of floating point then you won't need to live with its problems.

Some problems with floating point:
0.1 * 10 != 1
a+(b+c) != (a+b)+c

But does RRDtool need floating point arithmetics?

Inputs:
Time, a whole number of seconds, milliseconds, microseconds,
whatever but still an integer. Quite often, maybe always, there
is a relatively small delta, not somewhere near 2^100.
Counter values: also integers. Also usually a small range.

Outputs: an even more limited set of numbers, integer again.

(I believe the correct term to use is "scaled integers")

I am just wondering if it wouldn't be better to use integer
calculations and live with the fact that you cannot represent
a fraction of a {milli|micro}second, or counter values above
2^64, or whatever limitation this would incur.

I guess what I am asking is this: do you want a tool that is
fair at doing math in a really wide range of numbers (distances
between stars but also distances between cells) or do you want
a tool that is really good at keeping SNMP (alike) values and
rates?

cheers
Alex



More information about the rrd-developers mailing list