Send Beginners mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://www.haskell.org/mailman/listinfo/beginners
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Beginners digest..."
Today's Topics:
1. Re: truncate results depend on strict/lazy (Kim-Ee Yeoh)
2. Re: truncate results depend on strict/lazy (Bryan Vicknair)
3. Re: truncate results depend on strict/lazy (Brandon Allbery)
----------------------------------------------------------------------
Message: 1
Date: Tue, 10 Sep 2013 05:26:08 +0700
From: Kim-Ee Yeoh <[email protected]>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <[email protected]>
Subject: Re: [Haskell-beginners] truncate results depend on
strict/lazy
Message-ID:
<CAPY+ZdQ3URq7ANU7Zmdbm=xyuqchm_ddinqnz2rsfvjpnzw...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
On Tue, Sep 10, 2013 at 5:08 AM, Bryan Vicknair <[email protected]> wrote:
> And all of a sudden, the parsing code doesn't work again!:
>
> Prelude Data.Text Lib> validateVal $ pack "0.12"
> Success (Just 11)
>
This might be due to a floating-point roundoff error since 0.12 doesn't
have a finite binary representation.
The function truncate does exactly what it says, so truncate (100 *
0.1199999) evaluates to 11.
Are you sure you don't want "round" instead of "truncate"?
-- Kim-Ee
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.haskell.org/pipermail/beginners/attachments/20130910/4beec3c3/attachment-0001.html>
------------------------------
Message: 2
Date: Mon, 9 Sep 2013 17:03:50 -0700
From: Bryan Vicknair <[email protected]>
To: [email protected]
Subject: Re: [Haskell-beginners] truncate results depend on
strict/lazy
Message-ID: <20130910000350.GA539@bry-m6300>
Content-Type: text/plain; charset=us-ascii
On Tue, Sep 10, 2013 at 05:26:08AM +0700, Kim-Ee Yeoh wrote:
> On Tue, Sep 10, 2013 at 5:08 AM, Bryan Vicknair <[email protected]> wrote:
>
> > And all of a sudden, the parsing code doesn't work again!:
> >
> > Prelude Data.Text Lib> validateVal $ pack "0.12"
> > Success (Just 11)
> >
>
> This might be due to a floating-point roundoff error since 0.12 doesn't
> have a finite binary representation.
>
> The function truncate does exactly what it says, so truncate (100 *
> 0.1199999) evaluates to 11.
>
> Are you sure you don't want "round" instead of "truncate"?
>
> -- Kim-Ee
My first thought, as always with Floats, is that there was a binary
representation problem. If it were just that I wouldn't mind, but it is the
inconsistent evaluation of the following expression that is really bothering
me:
> truncate ((0.12::Float) * (100::Float))
In GHCI, I get 12:
> let f = 0.12::Float
> truncate (f * 100)
truncate ((0.12::Float) * (100::Float))
But in my web app and in this project it gives me 11:
https://bitbucket.org/bryanvick/truncate/overview
Whatever the behavior of truncate is, given the same input it should give the
same output. In the project referenced above, the input to validateVal and
unsafeValidateVal is always "0.12", but the output is 11 for the first and 12
for the second. The only difference between the two functions is that the
unsafe version performs IO.
------------------------------
Message: 3
Date: Mon, 9 Sep 2013 20:28:48 -0400
From: Brandon Allbery <[email protected]>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <[email protected]>
Subject: Re: [Haskell-beginners] truncate results depend on
strict/lazy
Message-ID:
<cakfcl4uqjnjngiut8nzphmmc4s-k6pmfkfnsj9axic3gwg+...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
On Mon, Sep 9, 2013 at 8:03 PM, Bryan Vicknair <[email protected]> wrote:
> Whatever the behavior of truncate is, given the same input it should give
> the
> same output.
>
An ideal, but unlikely when floating point is involved; optimization can
result in altered evaluation order or removal (or even addition in some
cases) of load/stores which can modify the internal representation. Note
that ghci is completely unoptimized.
--
brandon s allbery kf8nh sine nomine associates
[email protected] [email protected]
unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.haskell.org/pipermail/beginners/attachments/20130909/3bd5ce26/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
Beginners mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/beginners
------------------------------
End of Beginners Digest, Vol 63, Issue 14
*****************************************
