[Ns-developers] bug 441 and DataRates

[Mathieu Lacage]

On Wed, 2008-12-10 at 12:49 -0500, Raj Bhattacharjea wrote:
> Bug 441 (http://www.nsnam.org/bugzilla/show_bug.cgi?id=441) makes me wonder
> about the internal representation of the DataRate class, and our mostly off
> list discussion from from March 2007 (starting 3/13/2007).
> 
> My initial thoughts on that class were to make its internal bps figure be of
> type TimeUnit<-1>, so that such calculations could naturally work with
> multiplication and division, assuming the DataRate operators pass through to
> the TimeUnit operators.  In this case, what would happen internally:

I already said that many times but the idea that you can define
non-symetric C++ operators is wholly naive (stronger adjective elided).
i.e., if you define:

U operator + (V, W);

, you will die a horrible painful death (probably not immediately,
unfortunately). The only implementable option is to make DataRate is-a
TimeUnit<-1> just like Scalar is-a TimeUnit<0> with a typedef (don't
even think of trying to derive from TimeUnit<-1> because it won't work:
the "Seconds" class was derived from TimeUnit<1>  previously). That
would leave you with the task of figuring out how to name the function
used to create a DataRate from a string:
DataRate DataRateFromString (std::string str);
and, probably, with the task of defining a bunch of functions inspired
from the Seconds/MicroSeconds functions: BitsPerSecond,
KiloBitsPerSecond, BytesPerSecond, etc.

Erm, if you want to push this forward, don't tell anyone I suggested
it :)

> TimeUnit<-1> bps;
> TimeUnit<1> delta;
> Scalar bits = (bps*delta);
> bits.GetDouble() ...
> 
> But at the time I thought of this, as I recall the HighPrecision class
> division was very slow (for things like txtime = bits/bps), and I'm not sure
> if this has changed.  So doubles were proposed for the internal

Of course it is slow, but the question is whether it matters. For
practical purposes, I suspect that it does not but only profiling
evidence would tell you for sure.

The following is probably irrelevant but, what I think is interesting
about this specific bug is that it outlines two very different problems:

  a) the need for a sufficiently-high precision in certain temporary
results for seemingly-simple arithmetic operations to ensure a correct
final result

  b) the need for _the same_ precision on every platform in certain
temporary results for seemingly-simple arithmetic operations to ensure
the same final result all the time (the value of the final result does
not matter very much)

The real problem in this bug report is b) and the best way to solve it
is to _not_ use doubles. Making it easier to get to b) would be great
which is why I think your proposal to try to integrate the DataRate
class better with the TimeUnit<X> classes makes sense. The "only"
problem is figuring out how to do this (I did not even consider
practical problems such as the potential disruption of existing code):
it's going to be hard to nail down all the corner cases.

Mathieu