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<lemm...@henning-thielemann.de> wrote: > > 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. > _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe