On Aug 28, 2009, at 03:24 , Ketil Malde wrote:
What puzzled me (and the parent article indicated), was that Python
appeared to be able to work with more precision, and thus be more
"numerically correct" than GHC. Since it's all machine precision
floating point, this is even more strange, and I c
Lennart Augustsson writes:
> Prelude> toRational 697.04157958259998
> 3065621287177675 % 4398046511104
> Prelude> toRational 697.0415795826
> 3065621287177675 % 4398046511104
> As you can see, both numbers are represented by the same Double.
> Haskell prints a Double with the simplest number tha
Prelude> toRational 697.04157958259998
3065621287177675 % 4398046511104
Prelude> toRational 697.0415795826
3065621287177675 % 4398046511104
As you can see, both numbers are represented by the same Double.
Haskell prints a Double with the simplest number that converts back to
the same bit pattern.
Steve writes:
> Also, I had a problem using floating point in Python where
round(697.04157958254996, 10)
> gave
> 697.04157958259998
> Its been fixed in the latest versions of Python:
round(697.04157958254996, 10)
> 697.0415795825
> ghci> roundN 697.04157958254996 10
> 697.041579
2009/8/22 Roberto López
>
> You get the accuracy value in Perl, but there is the same problem in
> Python.
> It's a bit discouraging.
>
You don't get an accurate answer with Perl. It just lies to you to keep you
happy in your ignorance.
$ perl -e 'printf "%.22f\n", log(1000)/log(10);'
2.999
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
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 s
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 "he
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. yo
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
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.
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 g
Sun, Aug 23, 2009 at 12:41 PM, Steve wrote:
> On Sat, 2009-08-22 at 13:03 -0400, haskell-cafe-requ...@haskell.org
> wrote:
>> Message: 10
>> Date: Sat, 22 Aug 2009 11:24:21 +0200
>> From: Roberto L?pez
>> Subject: [Haskell-cafe] Re: Is logBase right?
>> To: haskel
2009/8/23 Steve :
> On Sat, 2009-08-22 at 13:03 -0400, haskell-cafe-requ...@haskell.org
> wrote:
>> Message: 10
>> Date: Sat, 22 Aug 2009 11:24:21 +0200
>> From: Roberto L?pez
>> Subject: [Haskell-cafe] Re: Is logBase right?
>> To: haskell-cafe@haskell.org
&
On Sat, 2009-08-22 at 13:03 -0400, haskell-cafe-requ...@haskell.org
wrote:
> Message: 10
> Date: Sat, 22 Aug 2009 11:24:21 +0200
> From: Roberto L?pez
> Subject: [Haskell-cafe] Re: Is logBase right?
> To: haskell-cafe@haskell.org
> Message-ID:
> Content-Type: text/plain
2009/8/22 Roberto López :
> If 4.0 / 2.0 was 1.98, 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.
Am Samstag 22 August 2009 11:34:51 schrieb Eugene Kirpichov:
> 2009/8/22 Roberto López :
> > If 4.0 / 2.0 was 1.98, 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 c
Even in Perl you've got
MigMit:~ MigMit$ perl -e 'printf("%.20f\n",log(125)/log(5))'
3.00044409
On 22 Aug 2009, at 13:24, Roberto López wrote:
If 4.0 / 2.0 was 1.98, it would be ok?
The real value of log10 1000 is 3 (3.0). It can be represented with
accuracy
2009/8/22 Roberto López :
> If 4.0 / 2.0 was 1.98, 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 acc
If 4.0 / 2.0 was 1.98, 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 y
20 matches
Mail list logo
