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,
T
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
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
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
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
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
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
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 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
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
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 ran
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
> 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
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
17 matches
Mail list logo