Is logBase right?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Is logBase right?

Roberto López
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
Reply | Threaded
Open this post in threaded view
|

Re: Is logBase right?

Eugene Kirpichov
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
Reply | Threaded
Open this post in threaded view
|

Re: Is logBase right?

Mark Wotton
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
Reply | Threaded
Open this post in threaded view
|

Re: Is logBase right?

Roberto López
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
Reply | Threaded
Open this post in threaded view
|

Re: Re: Is logBase right?

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. 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
Reply | Threaded
Open this post in threaded view
|

Re: Re: Is logBase right?

MigMit
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
Reply | Threaded
Open this post in threaded view
|

Re: Re: Is logBase right?

Daniel Fischer-4
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
Reply | Threaded
Open this post in threaded view
|

Re: Re: Is logBase right?

Magnus Therning
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
Reply | Threaded
Open this post in threaded view
|

Re: Is logBase right?

Steven Chaplin
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
Reply | Threaded
Open this post in threaded view
|

Re: Re: Is logBase right?

Eugene Kirpichov
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
Reply | Threaded
Open this post in threaded view
|

Re: Re: Is logBase right?

Lennart Augustsson
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
Reply | Threaded
Open this post in threaded view
|

Re: Re: Is logBase right?

Felipe Lessa
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
Reply | Threaded
Open this post in threaded view
|

Re: Re: Is logBase right?

Steven Chaplin
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
Reply | Threaded
Open this post in threaded view
|

Re[2]: Re: Is logBase right?

Bulat Ziganshin-2
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
Reply | Threaded
Open this post in threaded view
|

Re: Is logBase right?

Steven Chaplin
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
>
>
I think its 16 or 17 (significant not decimal digits). Its a miracle
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
Reply | Threaded
Open this post in threaded view
|

Re: Re: Is logBase right?

Daniel Fischer-4
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
Reply | Threaded
Open this post in threaded view
|

Re: Is logBase right?

Dan Weston
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
Reply | Threaded
Open this post in threaded view
|

Re: Re: Is logBase right?

Henning Thielemann
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
Reply | Threaded
Open this post in threaded view
|

Re: Re: Is logBase right?

Lennart Augustsson
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
Reply | Threaded
Open this post in threaded view
|

Re: Is logBase right?

Jeff Heard
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
12