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
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,
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
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 be
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,
On Fri, Sep 20, 2013 at 12:17 PM, damodar kulkarni
kdamodar2...@gmail.comwrote:
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
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
On Fri, Sep 20, 2013 at 11:17 AM, damodar kulkarni kdamodar2...@gmail.com
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
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
On Fri, Sep 20, 2013 at 6:17 PM, damodar kulkarni kdamodar2...@gmail.comwrote:
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
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 precision
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
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
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
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
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 read
On Fri, Sep 20, 2013 at 7:35 PM, damodar kulkarni kdamodar2...@gmail.com
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
17 matches
Mail list logo
