I don't really care much one way or the other, but since C (math.h)
provides functions for base 2 and base 10 with some additional
accuracy, I wouldn't mind using them. For a constant base I'd expect
the extra comparison to be constant folded, so that's ok. For a
non-constant base there would be a small penalty.
-- Lennart
On Tue, Aug 25, 2009 at 3:20 PM, Henning
Thielemann
On Sun, 23 Aug 2009, Lennart Augustsson wrote:
You're absolutely right. It would be easy to change logBase to have special cases for, say, base 2 and base 10, and call the C library functions for those. In fact, I think it's a worth while change, since it's easy and get's better results for some cases.
I think, the current implementation should left as it is. For fractional bases, no one would easily detect such imprecise results and report them as problem. So, it seems like people need a logarithm of integers, so they should be supplied with a special logarithm function for integers. For the other use cases, where 10 as base is one choice amongst a continuous set of rational numbers it would not be a problem to give the imprecise result. In the general case I would not accept a speed loss due to a check against 2 and 10 as base.
In dynamically typed languages like Python this might be different, because their users might not care much about types. It may not be important for them, whether a number is an integer or a floating point number that is accidentally integral. However, Python distinguishes between these two kinds of integers, but only dynamically.