[Haskell-cafe] Mystery of an Eq instance

2013-09-20 Thread damodar kulkarni
Hello, There were some recent discussions on the floating point support in Haskell and some not-so-pleasant "surprises" people encountered. There is an Eq instance defined for these types! So I tried this: *Main> sqrt (10.0) ==3.1622776601683795 True *Main> sqrt (10.0) ==3.16227766016837956 True

Re: [Haskell-cafe] Mystery of an Eq instance

2013-09-20 Thread Scott Lawrence
On ghc 7.6.3: Prelude> 3.16227766016837956 3.1622776601683795 So if you specify a number with greater-than-available precision, it will be truncated. This isn't an issue with (==), but with the necessary precision limitations of Double. On Fri, 20 Sep 2013, damodar kulkarni wrote: Hello, T

[Haskell-cafe] Which builder to choose?

2013-09-20 Thread Alejandro Serrano Mena
Hi, I'm looking at the packages blaze-builder and bytestring, and both provide builders for ByteString. Which one should I use? In which situations is one more convenient than the other? Thanks for the help. ___ Haskell-Cafe mailing list Haskell-Cafe@has

Re: [Haskell-cafe] Which builder to choose?

2013-09-20 Thread Duncan Coutts
On Fri, 2013-09-20 at 14:57 +0200, Alejandro Serrano Mena wrote: > Hi, > I'm looking at the packages blaze-builder and bytestring, and both provide > builders for ByteString. > Which one should I use? In which situations is one more convenient than the > other? I'd say the usual answer here would

Re: [Haskell-cafe] Mystery of an Eq instance

2013-09-20 Thread Albert Y. C. Lai
On 13-09-20 07:47 AM, damodar kulkarni wrote: *Main> sqrt (10.0) ==3.1622776601683795 True [...] *Main> sqrt (10.0) ==3.16227766016837956435443343 True This is not even specific to Haskell. Every language that provides floating point and floating point equality does this. (To date, P(provi

Re: [Haskell-cafe] Mystery of an Eq instance

2013-09-20 Thread Brandon Allbery
On Fri, Sep 20, 2013 at 12:17 PM, damodar kulkarni wrote: > Ok, let's say it is the effect of truncation. But then how do you explain > this? > > Prelude> sqrt 10.0 == 3.1622776601683795 > True > Prelude> sqrt 10.0 == 3.1622776601683796 > True > Because there's no reliable difference there. The t

Re: [Haskell-cafe] Mystery of an Eq instance

2013-09-20 Thread Tom Ellis
On Fri, Sep 20, 2013 at 06:34:04PM +0200, Stijn van Drongelen wrote: > Please find yourself a copy of "What Every Computer Scientist Should Know > About Floating-Point Arithmetic" by David Goldberg, and read it. It should > be very enlightening. It explains a bit about how IEEE754, pretty much the

Re: [Haskell-cafe] Mystery of an Eq instance

2013-09-20 Thread Mike Meyer
On Fri, Sep 20, 2013 at 11:17 AM, damodar kulkarni wrote: > Ok, let's say it is the effect of truncation. But then how do you explain this? Oh, it's a trunaction error all right. > Prelude> sqrt 10.0 == 3.1622776601683795 > True > Prelude> sqrt 10.0 == 3.1622776601683796 > True > > Here, the las

Re: [Haskell-cafe] Mystery of an Eq instance

2013-09-20 Thread damodar kulkarni
Ok, let's say it is the effect of truncation. But then how do you explain this? Prelude> sqrt 10.0 == 3.1622776601683795 True Prelude> sqrt 10.0 == 3.1622776601683796 True Here, the last digit **within the same precision range** in the fractional part is different in the two cases (5 in the first

Re: [Haskell-cafe] Mystery of an Eq instance

2013-09-20 Thread Stijn van Drongelen
On Fri, Sep 20, 2013 at 6:17 PM, damodar kulkarni wrote: > Ok, let's say it is the effect of truncation. But then how do you explain > this? > > Prelude> sqrt 10.0 == 3.1622776601683795 > True > Prelude> sqrt 10.0 == 3.1622776601683796 > True > > Well, that's easy: λ: decodeFloat 3.1622776601

Re: [Haskell-cafe] Mystery of an Eq instance

2013-09-20 Thread Tom Ellis
On Fri, Sep 20, 2013 at 09:47:24PM +0530, damodar kulkarni wrote: > Ok, let's say it is the effect of truncation. But then how do you explain > this? > > Prelude> sqrt 10.0 == 3.1622776601683795 > True > Prelude> sqrt 10.0 == 3.1622776601683796 > True > > Here, the last digit **within the same pr

Re: [Haskell-cafe] PSA: do not install xcode 5 if you are using ghc 7.6

2013-09-20 Thread Adam Foltzer
Hi Carter, Thanks for this heads up! Many of us here are cutting edge Mac users, and would have been bitten by this. Darin and I plan to spend some time next month preparing an unofficial > patched version of ghc 7.6 that should play nice with clang / xcode 5, > though at such a time ghc 7.8 will

Re: [Haskell-cafe] PSA: do not install xcode 5 if you are using ghc 7.6

2013-09-20 Thread Carter Schonwald
glad to help. an alternative for the discerning power user is to install a recent version of gcc locally (eg 4.8), and build 7.6.3 with that! (or just repoint your ghc settings file to a locally built version of real gcc.) yes, assuming we have the time (after all, it's all volunteer time), that

[Haskell-cafe] Music update

2013-09-20 Thread Mark Lentczner
Some might remember me asking about music packages a while back... An update: I ended up using Euterpea, which in turn uses both Codec.Midi and Sound.PortMidi. My working environment was to have my code loaded up in ghci, play MIDI into a software MIDI bus, and pipe that into MainStage 3 which ran

[Haskell-cafe] Demarcating monad transformers.

2013-09-20 Thread Nickolay Kudasov
Hi Café, Below I describe what I call «demarcating monad transformer». It works great for my purposes, though the construction feels a bit awkward. Perhaps, this is just an instance of a general case. For details and example, see [1] (single module package). Recently I got a challenge of manipula

Re: [Haskell-cafe] Mystery of an Eq instance

2013-09-20 Thread damodar kulkarni
> It seems to me that you're not familiar with the intricacies of > floating-point arithmetic. You're not alone, it's one of the top questions > on StackOverflow. > > Please find yourself a copy of "What Every Computer Scientist Should Know > About Floating-Point Arithmetic" by David Goldberg, and

Re: [Haskell-cafe] Mystery of an Eq instance

2013-09-20 Thread Mike Meyer
On Fri, Sep 20, 2013 at 7:35 PM, damodar kulkarni wrote: > This seems a good step forward, removing the Eq instance altogether on > floating point types would be much better; (unless as pointed out by > Brandon, "you have a very clever representation that can store > (floats) in terms of some oper