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)
4. Re: truncate results depend on strict/lazy (Bryan Vicknair)
5. Re: truncate results depend on strict/lazy (David McBride)
6. newbie's perplexities about instance of "Info a" of Chapter
13 (Thompson's Haskell book) (Carmine Moleti)
7. 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>
------------------------------
Message: 4
Date: Tue, 10 Sep 2013 10:14:56 -0700
From: Bryan Vicknair <[email protected]>
To: [email protected]
Subject: Re: [Haskell-beginners] truncate results depend on
strict/lazy
Message-ID: <20130910171456.GB539@bry-m6300>
Content-Type: text/plain; charset=us-ascii
On Mon, Sep 09, 2013 at 08:28:48PM -0400, Brandon Allbery wrote:
> 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.
Thanks everyone for the help. I think I'll write my own parsing code instead
of using reads and truncate. I really don't like floats. The whole reason
this parsing code exists is so that the DB can store a simple integer instead
of a float, but I still need to show the value as a float to the users.
This is scary though. This is the first leak I've found in the referential
transparency abstraction in Haskell (besides unsafePerformIO). And the problem
is, if I don't have referential transparency for 100% of pure functions, then I
have to be suspicious of every one. I can use some heuristics to narrow down
the suspects, such as questioning floating point functions first, but I just
had my bubble burst nonetheless.
Is there any resource that compiles all the potential exceptions to the Haskell
abstract machine?
------------------------------
Message: 5
Date: Tue, 10 Sep 2013 13:31:49 -0400
From: David McBride <[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:
<CAN+Tr42XBDec5hiaHt1-8hVGy8wMs9BT=g8p7wdrc-6tkg2...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Whenever I have to deal with precision issues I try to remove floats and
doubles from the equation entirely.
> toRational (0.12 :: Float)
16106127 % 134217728
> toRational (0.12 :: Double)
1080863910568919 % 9007199254740992>
truncate $ (toRational (0.12 :: Float)* 100)
11
truncate $ (toRational (0.12 :: Double)* 100)
11
Wrong, but at least it is consistently wrong and should not be interpreted
differently regardless of optimizations.
On Tue, Sep 10, 2013 at 1:14 PM, Bryan Vicknair <[email protected]> wrote:
> On Mon, Sep 09, 2013 at 08:28:48PM -0400, Brandon Allbery wrote:
> > 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.
>
> Thanks everyone for the help. I think I'll write my own parsing code
> instead
> of using reads and truncate. I really don't like floats. The whole reason
> this parsing code exists is so that the DB can store a simple integer
> instead
> of a float, but I still need to show the value as a float to the users.
>
> This is scary though. This is the first leak I've found in the referential
> transparency abstraction in Haskell (besides unsafePerformIO). And the
> problem
> is, if I don't have referential transparency for 100% of pure functions,
> then I
> have to be suspicious of every one. I can use some heuristics to narrow
> down
> the suspects, such as questioning floating point functions first, but I
> just
> had my bubble burst nonetheless.
>
> Is there any resource that compiles all the potential exceptions to the
> Haskell
> abstract machine?
> _______________________________________________
> Beginners mailing list
> [email protected]
> http://www.haskell.org/mailman/listinfo/beginners
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.haskell.org/pipermail/beginners/attachments/20130910/a2345546/attachment-0001.html>
------------------------------
Message: 6
Date: Tue, 10 Sep 2013 17:59:12 +0000 (UTC)
From: Carmine Moleti <[email protected]>
To: [email protected]
Subject: [Haskell-beginners] newbie's perplexities about instance of
"Info a" of Chapter 13 (Thompson's Haskell book)
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hi to everyone,
I'm learning Haskell going through Thompson's craft of functional
programming (3rd ed).
As of now I've reached Chapter 13 where classes definition and instances are
discussed.
At some point the "Info a" class is introduced which has the following
interface:
class Info a where
examples :: [a]
size :: a -> Int
then it goes on explaining that every instance of that class must comply to
the interface shown. So far so good.
My perplexities start when actual instances are implemented.
Take, for example the following one:
instance Info Int where
examples = [-100..100]
size _ = 1
I promptly tried to fiddle with this via ghci and while I was able to access
the "size" function of the interface I have no clue about how to reach the
"examples" part and that prevents me from understanding the next
step when an instance of "Info [a]" is discussed.
About that I don't quite get the definition of its "examples", and the
reasons it is defined taking into accounts "all the one and two element
lists that can be built up from exmaples of type a" (cit.)
Can anyone shed some light about this, please?
Thanks in advance for your help.
Best regards,
Carmine
------------------------------
Message: 7
Date: Tue, 10 Sep 2013 14:06:17 -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:
<CAKFCL4X=BtePHCbk3WAKiD_zim-Gu74=qsapsfh7im+h29q...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
On Tue, Sep 10, 2013 at 1:14 PM, Bryan Vicknair <[email protected]> wrote:
> This is scary though. This is the first leak I've found in the referential
> transparency abstraction in Haskell (besides unsafePerformIO). And the
> problem
> is, if I don't have referential transparency for 100% of pure functions,
> then I
> have to be suspicious of every one.
>
It's not quite *that* bad. Floating point is a well known source of
confusion, except to beginners; there are "why did it do this why is your
language broken waaa" posts from people discovering floating point in every
single programming language that supports them. You *cannot* 100%
accurately store numbers that can have infinite precision in a limited
address space. And the representation has its own issues, since computers
work best in powers of 2 but we work in powers of 10; numbers that are
finite in a decimal representation may be repeating infinite values in a
normalized base 2 floating representation.
(There are types such as CReal which attempt to keep arbitrary precision.
This breaks down as soon as you try to use them with transcendentals. There
is no finite *and* 100% accurate representation of pi.)
Aside from this, the only other "leaks" you're likely to ever encounter
(absent unsafePerformIO and friends) are other cases of physical hardware
being less perfect than mathematical abstraction, which is to say running
out of memory (by far the most common, but also the most amenable to
modification/correction), hardware failures, memory bit-flips, etc. At some
point, physical constraints are going to win because we can't run programs
on abstract mathematical theories, we have to run them on (however
abstracted) physical systems.
But practically, floating point is the main place where things go south;
and yes, it's generally hated in the functional programming community: no
matter what you do, real numbers are going to be a pain, and the standard
compromise known as floating point is especially frustrating because its
behavior can't be captured in a simple functional description. But floating
point is what CPUs use and have specific support for.
--
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/20130910/51747db1/attachment.html>
------------------------------
Subject: Digest Footer
_______________________________________________
Beginners mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/beginners
------------------------------
End of Beginners Digest, Vol 63, Issue 14
*****************************************
