On Mar 23, 2007, at 16:59:02, H. Peter Anvin wrote:
Randy Dunlap wrote:
Hi,
That makes a lot of sense to me. It gives us finer-grained
control without having to support fixed-point data. I've been
working on the fixed-point data patch, but I'm going to give this
method some time also, to see how it looks in code (instead of
just thinking about it).
Well, to be specific, it actually is the same thing with different
syntax (38.55 or 3855/100).
Not quite; if you're dealing with numbers near the limit of the range
of "int" then IIRC fixed point is harder to get both good accuracy
and good overflow behavior compared to a user-set fraction:
Assuming "fraction" is a reduce (num, den) pair, then to compute
"result = value * fraction" with optimal accuracy:
/* On input: reduce num/den but retain old values for display
purposes */
gcd = euclid(&inputnum, &inputden);
num = inputnum/gcd;
den = inputden/gcd;
valmax = UINT_MAX / num;
/* For computation: */
result = (val > valmax) ? (val/den)*num : (val*num)/den;
Doing that with fixed point is possible, but a bit more tricky, and
you lose accuracy for something like "1/3", which isn't quite equal
to "0.3333". Note that if you aren't really careful with your fixed-
point then "0.3333 * 3" ends up being 0: (3333 * 3) / 10000 ==
9999 / 10000 == 0. Rounding is possible but it's better to just let
them specify the exact fraction directly and avoid the confusion.
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
