[Haskell-cafe] Re: Defaulting to Rational [was: Number overflow]

2007-07-14 Thread Jon Fairbairn
Jonathan Cast [EMAIL PROTECTED] writes: On Friday 13 July 2007, Jon Fairbairn wrote: Henning Thielemann [EMAIL PROTECTED] writes: On Thu, 12 Jul 2007, Jon Fairbairn wrote: Surely the first few digits can be computed? That was my first thought, too. We can't define data Real =

[Haskell-cafe] Re: Defaulting to Rational [was: Number overflow]

2007-07-13 Thread Jon Fairbairn
Henning Thielemann [EMAIL PROTECTED] writes: On Thu, 12 Jul 2007, Jon Fairbairn wrote: (ie limited precision, but unbounded magnitude). If we were to use BigFloat the base would need to be a power of ten to get the desired results for things like Don's example) People will be confused,

Re: [Haskell-cafe] Re: Defaulting to Rational [was: Number overflow]

2007-07-13 Thread Jonathan Cast
On Friday 13 July 2007, Jon Fairbairn wrote: Henning Thielemann [EMAIL PROTECTED] writes: On Thu, 12 Jul 2007, Jon Fairbairn wrote: (ie limited precision, but unbounded magnitude). If we were to use BigFloat the base would need to be a power of ten to get the desired results for things

[Haskell-cafe] Re: Defaulting to Rational [was: Number overflow]

2007-07-12 Thread apfelmus
Donald Bruce Stewart wrote: should Rational, or something similar be used instead, given that Doubles and Float are broken for a lot of basic things (like Eq and Ord), much as we default to Integer already. The issues raised regarding Rational was that you can unexpectedly build up large

Re: [Haskell-cafe] Re: Defaulting to Rational [was: Number overflow]

2007-07-12 Thread Henning Thielemann
On Thu, 12 Jul 2007, Jon Fairbairn wrote: Now, a proper exact real type is doubtless very inefficient, but wouldn't it be possible to define something that had a fairly efficient head, and a lazy tail? So you'd have, say data Real = R {big::(Ratio !Int !Int), small:: More_Precision} for

[Haskell-cafe] Re: Defaulting to Rational [was: Number overflow]

2007-07-12 Thread Jon Fairbairn
Henning Thielemann [EMAIL PROTECTED] writes: On Thu, 12 Jul 2007, Jon Fairbairn wrote: Now, a proper exact real type is doubtless very inefficient, but wouldn't it be possible to define something that had a fairly efficient head, and a lazy tail? So you'd have, say data Real = R

[Haskell-cafe] Re: Defaulting to Rational [was: Number overflow]

2007-07-12 Thread apfelmus
Bryan O'Sullivan wrote: apfelmus wrote: In a sense, the instances of Eq and Ord for floating point numbers are wrong. What about rolling new classes for approximate equality and ordering? class ApproxEq a where (≈) :: a - a - Bool -- almost equal to The problems with this

Re: [Haskell-cafe] Re: Defaulting to Rational [was: Number overflow]

2007-07-12 Thread Henning Thielemann
On Thu, 12 Jul 2007, Jon Fairbairn wrote: Henning Thielemann [EMAIL PROTECTED] writes: On Thu, 12 Jul 2007, Jon Fairbairn wrote: Now, a proper exact real type is doubtless very inefficient, but wouldn't it be possible to define something that had a fairly efficient head, and a

Re: [Haskell-cafe] Re: Defaulting to Rational [was: Number overflow]

2007-07-12 Thread ok
On 13 Jul 2007, at 2:58 am, apfelmus wrote: What I wanted to do is to capture common patterns x - y = epsilon abs (x - y) = epsilon for comparing floating point numbers in nice functions x y = x - y = epsilon x ≈ y = abs (x - y) = epsilon See Knuth, The Art of Computer