Hi,
There is a mistake is logBase: $ ghci GHCi, version 6.10.4: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Prelude> logBase 10 10 1.0 Prelude> logBase 10 100 2.0 Prelude> logBase 10 1000 2.9999999999999996 <--- eeeerrgghhhh! Prelude> logBase 10 10000 4.0 My host is a Debian GNU/Linux 5.0.2 (lenny) with the following GHC packages: ii ghc6 6.10.4-1 ii ghc6-doc 6.10.4-1 ii libghc6-mtl-dev 1.1.0.2-7+b1 ii libghc6-utf8-string-dev 0.3.5-1+b1 ii libghc6-x11-dev 1.4.5-6 rc libghc6-x11-doc 1.4.2-1 ii libghc6-x11-xft-dev 0.3-3+b3 ii libghc6-xmonad-contrib-dev 0.8.1-3+b3 rc libghc6-xmonad-contrib-doc 0.8-2 ii libghc6-xmonad-dev 0.8.1-5 Regards! _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
What do you consider to be the specification of logBase? Exact
floating-point numbers don't exist, so it has to return an approximation. The standard doesn't give any guarantees as to the precision of the approximation. Is a precision of 0.00000000000004 not satisfactory for you? 2009/8/21 Roberto <[hidden email]>: > Hi, > > There is a mistake is logBase: > > $ ghci > GHCi, version 6.10.4: http://www.haskell.org/ghc/ :? for help > Loading package ghc-prim ... linking ... done. > Loading package integer ... linking ... done. > Loading package base ... linking ... done. > Prelude> logBase 10 10 > 1.0 > Prelude> logBase 10 100 > 2.0 > Prelude> logBase 10 1000 > 2.9999999999999996 <--- eeeerrgghhhh! > Prelude> logBase 10 10000 > 4.0 > > > My host is a Debian GNU/Linux 5.0.2 (lenny) with the following GHC packages: > > ii ghc6 6.10.4-1 > ii ghc6-doc 6.10.4-1 > ii libghc6-mtl-dev 1.1.0.2-7+b1 > ii libghc6-utf8-string-dev 0.3.5-1+b1 > ii libghc6-x11-dev 1.4.5-6 > rc libghc6-x11-doc 1.4.2-1 > ii libghc6-x11-xft-dev 0.3-3+b3 > ii libghc6-xmonad-contrib-dev 0.8.1-3+b3 > rc libghc6-xmonad-contrib-doc 0.8-2 > ii libghc6-xmonad-dev 0.8.1-5 > > Regards! > > > _______________________________________________ > Haskell-Cafe mailing list > [hidden email] > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- Eugene Kirpichov Web IR developer, market.yandex.ru _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Roberto López
he who compares floating point numbers for equality is in a state of
sin. mark On 22/08/2009, at 5:00 AM, Roberto wrote: > Hi, > > There is a mistake is logBase: > > $ ghci > GHCi, version 6.10.4: http://www.haskell.org/ghc/ :? for help > Loading package ghc-prim ... linking ... done. > Loading package integer ... linking ... done. > Loading package base ... linking ... done. > Prelude> logBase 10 10 > 1.0 > Prelude> logBase 10 100 > 2.0 > Prelude> logBase 10 1000 > 2.9999999999999996 <--- eeeerrgghhhh! > Prelude> logBase 10 10000 > 4.0 > > > My host is a Debian GNU/Linux 5.0.2 (lenny) with the following GHC > packages: > > ii ghc6 6.10.4-1 > ii ghc6-doc 6.10.4-1 > ii libghc6-mtl-dev 1.1.0.2-7+b1 > ii libghc6-utf8-string-dev 0.3.5-1+b1 > ii libghc6-x11-dev 1.4.5-6 > rc libghc6-x11-doc 1.4.2-1 > ii libghc6-x11-xft-dev 0.3-3+b3 > ii libghc6-xmonad-contrib-dev 0.8.1-3+b3 > rc libghc6-xmonad-contrib-doc 0.8-2 > ii libghc6-xmonad-dev 0.8.1-5 > > Regards! > > > _______________________________________________ > Haskell-Cafe mailing list > [hidden email] > http://www.haskell.org/mailman/listinfo/haskell-cafe _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Eugene Kirpichov
If 4.0 / 2.0 was 1.9999999999999999999998, it would be ok?
The real value of log10 1000 is 3 (3.0). It can be represented with accuracy and it should be. You get the accuracy value in Perl, but there is the same problem in Python. It's a bit discouraging. Eugene Kirpichov wrote: > What do you consider to be the specification of logBase? Exact > floating-point numbers don't exist, so it has to return an > approximation. The standard doesn't give any guarantees as to the > precision of the approximation. Is a precision of 0.00000000000004 not > satisfactory for you? > _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
2009/8/22 Roberto López <[hidden email]>:
> If 4.0 / 2.0 was 1.9999999999999999999998, it would be ok? I think yes. However, hardware can afford to do computations "as accurately as possible", whereas software like Haskell Prelude can't. > > The real value of log10 1000 is 3 (3.0). It can be represented with accuracy > and it should be. Doing so would not be of much use and would impose a performance penalty required to achieve this accuracy. I looked into the Prelude source and saw that logBase is implemented like x`logBase`y = log x / log y. I think it is quite a sensible definition, and there's no point in modifying it just to make accuracy even better than 0.000000000000000004 in certain cases where it is possible. To my mind, an accuracy of "the representable number closest to the exact answer" is only required in very specific circumstances, for example when you are converting a string to a float. If you have a good reason to need exact real numbers, you can use a corresponding package for exact reals. However, if you propose an equivalently fast definition of logBase that achieves better accuracy, I am sure it will be much welcomed. > > You get the accuracy value in Perl, but there is the same problem in Python. > It's a bit discouraging. > > > Eugene Kirpichov wrote: > >> What do you consider to be the specification of logBase? Exact >> floating-point numbers don't exist, so it has to return an >> approximation. The standard doesn't give any guarantees as to the >> precision of the approximation. Is a precision of 0.00000000000004 not >> satisfactory for you? >> > > > _______________________________________________ > Haskell-Cafe mailing list > [hidden email] > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- Eugene Kirpichov Web IR developer, market.yandex.ru _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Roberto López
Even in Perl you've got
MigMit:~ MigMit$ perl -e 'printf("%.20f\n",log(125)/log(5))' 3.00000000000000044409 On 22 Aug 2009, at 13:24, Roberto López wrote: > If 4.0 / 2.0 was 1.9999999999999999999998, it would be ok? > > The real value of log10 1000 is 3 (3.0). It can be represented with > accuracy > and it should be. > > You get the accuracy value in Perl, but there is the same problem in > Python. > It's a bit discouraging. > > > Eugene Kirpichov wrote: > >> What do you consider to be the specification of logBase? Exact >> floating-point numbers don't exist, so it has to return an >> approximation. The standard doesn't give any guarantees as to the >> precision of the approximation. Is a precision of 0.00000000000004 >> not >> satisfactory for you? >> > > > _______________________________________________ > Haskell-Cafe mailing list > [hidden email] > http://www.haskell.org/mailman/listinfo/haskell-cafe _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Eugene Kirpichov
Am Samstag 22 August 2009 11:34:51 schrieb Eugene Kirpichov:
> 2009/8/22 Roberto López <[hidden email]>: > > If 4.0 / 2.0 was 1.9999999999999999999998, it would be ok? > > I think yes. I don't. Not for (+), (-), (*), (/). There I want "the representable number closest to the exact answer". > However, hardware can afford to do computations "as > accurately as possible", whereas software like Haskell Prelude can't. > > > The real value of log10 1000 is 3 (3.0). It can be represented with > > accuracy and it should be. > > Doing so would not be of much use and would impose a performance > penalty required to achieve this accuracy. +1 It is so rare that such functions have exactly representable results that it's absolutely not worth to check. Hence it is the programmer's obligation to test and adjust if it's moderately likely that such a case arises and it's important. _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Roberto López
2009/8/22 Roberto López <[hidden email]>:
> If 4.0 / 2.0 was 1.9999999999999999999998, it would be ok? > > The real value of log10 1000 is 3 (3.0). It can be represented with accuracy > and it should be. Well, it already can be, you just need to choose your representation properly: > logBase 10 1000 :: Double 2.9999999999999996 > logBase 10 1000 :: Float 3.0 Welcome the wonderful land of floating point numbers. (The examples above are from an Intel 32-bit machine, I suspect it'd change on any other type of architecture.) /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Roberto López
On Sat, 2009-08-22 at 13:03 -0400, [hidden email]
wrote: > Message: 10 > Date: Sat, 22 Aug 2009 11:24:21 +0200 > From: Roberto L?pez <[hidden email]> > Subject: [Haskell-cafe] Re: Is logBase right? > To: [hidden email] > Message-ID: <h6odg8$93j$[hidden email]> > Content-Type: text/plain; charset="ISO-8859-1" > > If 4.0 / 2.0 was 1.9999999999999999999998, it would be ok? > > The real value of log10 1000 is 3 (3.0). It can be represented with > accuracy > and it should be. > > You get the accuracy value in Perl, but there is the same problem in > Python. > It's a bit discouraging. > There is *not* the same problem in Python: $ python Python 2.6.2 (r262:71600, Jul 9 2009, 23:16:53) [GCC 4.4.0 20090506 (Red Hat 4.4.0-4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import math >>> math.log10(1000) 3.0 Recent work in Python 3 (and Python 2.6) has improved the handling of floating point numbers, and addresses exactly the problem that Roberto has raised. I see no reason why Haskell could not improve its handling of floating point numbers by using similar techniques. Steve _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
2009/8/23 Steve <[hidden email]>:
> On Sat, 2009-08-22 at 13:03 -0400, [hidden email] > wrote: >> Message: 10 >> Date: Sat, 22 Aug 2009 11:24:21 +0200 >> From: Roberto L?pez <[hidden email]> >> Subject: [Haskell-cafe] Re: Is logBase right? >> To: [hidden email] >> Message-ID: <h6odg8$93j$[hidden email]> >> Content-Type: text/plain; charset="ISO-8859-1" >> >> If 4.0 / 2.0 was 1.9999999999999999999998, it would be ok? >> >> The real value of log10 1000 is 3 (3.0). It can be represented with >> accuracy >> and it should be. >> >> You get the accuracy value in Perl, but there is the same problem in >> Python. >> It's a bit discouraging. >> > > There is *not* the same problem in Python: > $ python > Python 2.6.2 (r262:71600, Jul 9 2009, 23:16:53) > [GCC 4.4.0 20090506 (Red Hat 4.4.0-4)] on linux2 > Type "help", "copyright", "credits" or "license" for more information. >>>> import math >>>> math.log10(1000) > 3.0 > >>> import math >>> math.log(1000,10) 2.9999999999999996 > Recent work in Python 3 (and Python 2.6) has improved the handling of > floating point numbers, and addresses exactly the problem that Roberto > has raised. > > I see no reason why Haskell could not improve its handling of floating > point numbers by using similar techniques. You mean introducing a "log10" function into the definition of the Floating class ? That might be a proposal for Haskell Prime. > > Steve > > _______________________________________________ > Haskell-Cafe mailing list > [hidden email] > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- Eugene Kirpichov Web IR developer, market.yandex.ru _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Steven Chaplin
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. -- Lennart On Sun, Aug 23, 2009 at 12:41 PM, Steve<[hidden email]> wrote: > On Sat, 2009-08-22 at 13:03 -0400, [hidden email] > wrote: >> Message: 10 >> Date: Sat, 22 Aug 2009 11:24:21 +0200 >> From: Roberto L?pez <[hidden email]> >> Subject: [Haskell-cafe] Re: Is logBase right? >> To: [hidden email] >> Message-ID: <h6odg8$93j$[hidden email]> >> Content-Type: text/plain; charset="ISO-8859-1" >> >> If 4.0 / 2.0 was 1.9999999999999999999998, it would be ok? >> >> The real value of log10 1000 is 3 (3.0). It can be represented with >> accuracy >> and it should be. >> >> You get the accuracy value in Perl, but there is the same problem in >> Python. >> It's a bit discouraging. >> > > There is *not* the same problem in Python: > $ python > Python 2.6.2 (r262:71600, Jul 9 2009, 23:16:53) > [GCC 4.4.0 20090506 (Red Hat 4.4.0-4)] on linux2 > Type "help", "copyright", "credits" or "license" for more information. >>>> import math >>>> math.log10(1000) > 3.0 > > Recent work in Python 3 (and Python 2.6) has improved the handling of > floating point numbers, and addresses exactly the problem that Roberto > has raised. > > I see no reason why Haskell could not improve its handling of floating > point numbers by using similar techniques. > > Steve > > _______________________________________________ > Haskell-Cafe mailing list > [hidden email] > http://www.haskell.org/mailman/listinfo/haskell-cafe > Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
On Sun, Aug 23, 2009 at 01:25:14PM +0200, 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. For a short-term solution there's Don's cmath[1]. [1] http://hackage.haskell.org/packages/archive/cmath/0.3/doc/html/Foreign-C-Math-Double.html#v:log10 -- Felipe. _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Eugene Kirpichov
On Sun, 2009-08-23 at 15:12 +0400, Eugene Kirpichov wrote:
> > There is *not* the same problem in Python: > > $ python > > Python 2.6.2 (r262:71600, Jul 9 2009, 23:16:53) > > [GCC 4.4.0 20090506 (Red Hat 4.4.0-4)] on linux2 > > Type "help", "copyright", "credits" or "license" for more information. > >>>> import math > >>>> math.log10(1000) > > 3.0 > > > > >>> import math > >>> math.log(1000,10) > 2.9999999999999996 That is surprising. I think its a Python bug - the results should be consistent. > > > Recent work in Python 3 (and Python 2.6) has improved the handling of > > floating point numbers, and addresses exactly the problem that Roberto > > has raised. > > > > I see no reason why Haskell could not improve its handling of floating > > point numbers by using similar techniques. > > You mean introducing a "log10" function into the definition of the > Floating class ? That might be a proposal for Haskell Prime. I was not thinking of the log10 function. I was thinking of the changes mentioned in http://docs.python.org/3.1/whatsnew/3.1.html where it says "Python now uses David Gay’s algorithm for finding the shortest floating point representation that doesn’t change its value. This should help mitigate some of the confusion surrounding binary floating point numbers." Also, I had a problem using floating point in Python where >>> round(697.04157958254996, 10) gave 697.04157958259998 which is closer to 697.0415795826 than the desired result of 697.0415795825 Its been fixed in the latest versions of Python: >>> round(697.04157958254996, 10) 697.0415795825 I'm not sure what the equivalent in Haskell is. Is there a function for rounding to a number of decimal digits ? I came up with this: roundN :: Double -> Int -> Double roundN n ndigits = fromIntegral (round $ n * m) / m where m = 10 ^ ndigits ghci> roundN 697.04157958254996 10 697.0415795826 which is not the desired result. Steve _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
Hello Steve,
Sunday, August 23, 2009, 5:27:48 PM, you wrote: ghci>> roundN 697.04157958254996 10 > 697.0415795826 afair, double has 13 decimal digits precision, so your 697.04157958254996 represented by another value. you just looking for miracles -- Best regards, Bulat mailto:[hidden email] _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
On Sun, 2009-08-23 at 17:36 +0400, Bulat Ziganshin wrote:
> Hello Steve, > > Sunday, August 23, 2009, 5:27:48 PM, you wrote: > > ghci>> roundN 697.04157958254996 10 > > 697.0415795826 > > afair, double has 13 decimal digits precision, so your > 697.04157958254996 represented by another value. you just looking for > miracles > > that Python achieves! But Haskell does not. Python uses doubles too, and for certain operations it uses arbitrary precision floating point (I think). Steve _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Steven Chaplin
Am Sonntag 23 August 2009 15:27:48 schrieb Steve:
> On Sun, 2009-08-23 at 15:12 +0400, Eugene Kirpichov wrote: > > > There is *not* the same problem in Python: > > > $ python > > > Python 2.6.2 (r262:71600, Jul 9 2009, 23:16:53) > > > [GCC 4.4.0 20090506 (Red Hat 4.4.0-4)] on linux2 > > > Type "help", "copyright", "credits" or "license" for more information. > > > > > >>>> import math > > >>>> math.log10(1000) > > > > > > 3.0 > > > > > >>> import math > > >>> math.log(1000,10) > > > > 2.9999999999999996 > > That is surprising. I think its a Python bug - the results should be > consistent. On the other hand, it is also desirable to have log(a,b) == log(a)/log(b). If you have a special implementation of log10, you must decide which consistency you want to break, log(a,10) == log10(a) or log(a,10) == log(a)/log(10). > > > > Recent work in Python 3 (and Python 2.6) has improved the handling of > > > floating point numbers, and addresses exactly the problem that Roberto > > > has raised. > > > > > > I see no reason why Haskell could not improve its handling of floating > > > point numbers by using similar techniques. > > > > You mean introducing a "log10" function into the definition of the > > Floating class ? That might be a proposal for Haskell Prime. > > I was not thinking of the log10 function. I was thinking of the changes > mentioned in > http://docs.python.org/3.1/whatsnew/3.1.html > where it says > "Python now uses David Gay’s algorithm for finding the shortest floating > point representation that doesn’t change its value. This should help > mitigate some of the confusion surrounding binary floating point > numbers." Note however that that only concerns the output, not the underlying value. It doesn't change the fact that log(1000)/log(10) (== log(1000,10)) < 3 in Python, too. > > Also, I had a problem using floating point in Python where > > >>> round(697.04157958254996, 10) > > gave > 697.04157958259998 > which is closer to > 697.0415795826 > than the desired result of > 697.0415795825 Well, 10^10*(697.04157958254996 :: Double) == 6970415795825.5, that gets rounded to 6970415795826 under both, round-half-up and round-half-to-even, and (6970415795826/10^10 :: Double) == 697.04157958259998 Though ghci displays it as 697.0415795826, unlike Python. > > Its been fixed in the latest versions of Python: > >>> round(697.04157958254996, 10) > > 697.0415795825 > > > I'm not sure what the equivalent in Haskell is. Is there a function for > rounding to a number of decimal digits ? > I came up with this: > > roundN :: Double -> Int -> Double > roundN n ndigits = fromIntegral (round $ n * m) / m > where m = 10 ^ ndigits > > ghci> roundN 697.04157958254996 10 > 697.0415795826 > > which is not the desired result. Prelude Numeric> let roundN :: Double -> Int -> Double; roundN x d = let { m = 10^(d+1); i = floor (m*x); r = i `mod` 10; j = if r < 5 then i-r else i-r+10 } in fromInteger j/m roundN :: Double -> Int -> Double roundN x d = fromInteger j / m where m = 10^(d+1) i = floor (m*x) r = i `mod` 10 j | r < 5 = i-r | otherwise = i+10-r ghci> roundN 697.04157958254996 10 697.0415795825 I haven't treated negative input, but, more importantly, floating point representation being what it is, there are cases where this doesn't do what you want/expect either. > > Steve _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Roberto López
I don't know if anyone actually answered the question you didn't ask,
but you can always improve an inaccurate guess when you need to. A limit will always exist, and should be unique (independent of the initial guess), assuming (+) and (*) are well-conditioned. In practice, a single first-order Taylor step should be enough: logBase' :: Double -> Double -> Double logBase' b y = if b == 0.0 then 1.0 else improve x0 where bLogInv = 1.0 / log(b) f x = x + (1.0-b**x/y) * bLogInv -- First step is enough, if we guess smartly improve = f x0 = log(y) * bLogInv -- or use the limit from any initial guess -- improve x = let y = f x in if y == x then y else improve y -- x0 = 0.0 Dan Roberto wrote: > Hi, > > There is a mistake is logBase: > > $ ghci > GHCi, version 6.10.4: http://www.haskell.org/ghc/ :? for help > Loading package ghc-prim ... linking ... done. > Loading package integer ... linking ... done. > Loading package base ... linking ... done. > Prelude> logBase 10 10 > 1.0 > Prelude> logBase 10 100 > 2.0 > Prelude> logBase 10 1000 > 2.9999999999999996 <--- eeeerrgghhhh! > Prelude> logBase 10 10000 > 4.0 > > > My host is a Debian GNU/Linux 5.0.2 (lenny) with the following GHC packages: > > ii ghc6 6.10.4-1 > ii ghc6-doc 6.10.4-1 > ii libghc6-mtl-dev 1.1.0.2-7+b1 > ii libghc6-utf8-string-dev 0.3.5-1+b1 > ii libghc6-x11-dev 1.4.5-6 > rc libghc6-x11-doc 1.4.2-1 > ii libghc6-x11-xft-dev 0.3-3+b3 > ii libghc6-xmonad-contrib-dev 0.8.1-3+b3 > rc libghc6-xmonad-contrib-doc 0.8-2 > ii libghc6-xmonad-dev 0.8.1-5 > > Regards! > > > _______________________________________________ > Haskell-Cafe mailing list > [hidden email] > http://www.haskell.org/mailman/listinfo/haskell-cafe > > _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Lennart Augustsson
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 [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
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<[hidden email]> 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 [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Mark Wotton
I always thought that he who compares floating point numbers for
equality was acting in tangent of reason... -- Jeff On Sat, Aug 22, 2009 at 4:02 AM, Mark Wotton<[hidden email]> wrote: > he who compares floating point numbers for equality is in a state of sin. > > mark > > On 22/08/2009, at 5:00 AM, Roberto wrote: > >> Hi, >> >> There is a mistake is logBase: >> >> $ ghci >> GHCi, version 6.10.4: http://www.haskell.org/ghc/ :? for help >> Loading package ghc-prim ... linking ... done. >> Loading package integer ... linking ... done. >> Loading package base ... linking ... done. >> Prelude> logBase 10 10 >> 1.0 >> Prelude> logBase 10 100 >> 2.0 >> Prelude> logBase 10 1000 >> 2.9999999999999996 <--- eeeerrgghhhh! >> Prelude> logBase 10 10000 >> 4.0 >> >> >> My host is a Debian GNU/Linux 5.0.2 (lenny) with the following GHC >> packages: >> >> ii ghc6 6.10.4-1 >> ii ghc6-doc 6.10.4-1 >> ii libghc6-mtl-dev 1.1.0.2-7+b1 >> ii libghc6-utf8-string-dev 0.3.5-1+b1 >> ii libghc6-x11-dev 1.4.5-6 >> rc libghc6-x11-doc 1.4.2-1 >> ii libghc6-x11-xft-dev 0.3-3+b3 >> ii libghc6-xmonad-contrib-dev 0.8.1-3+b3 >> rc libghc6-xmonad-contrib-doc 0.8-2 >> ii libghc6-xmonad-dev 0.8.1-5 >> >> Regards! >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> [hidden email] >> http://www.haskell.org/mailman/listinfo/haskell-cafe > > _______________________________________________ > Haskell-Cafe mailing list > [hidden email] > http://www.haskell.org/mailman/listinfo/haskell-cafe > Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
Free forum by Nabble | Edit this page |