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: newbie's perplexities about instance of "Info a" of
Chapter 13 (Thompson's Haskell book) (David McBride)
2. Re: truncate results depend on strict/lazy (Oscar Benjamin)
3. Re: truncate results depend on strict/lazy (Brandon Allbery)
4. Re: truncate results depend on strict/lazy (Oscar Benjamin)
5. Re: truncate results depend on strict/lazy (Brandon Allbery)
----------------------------------------------------------------------
Message: 1
Date: Tue, 10 Sep 2013 14:12:41 -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] newbie's perplexities about instance
of "Info a" of Chapter 13 (Thompson's Haskell book)
Message-ID:
<can+tr43zen3eicgv58rnwysu+1auepzlqpzhrp2l3ndks6z...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
In ghci try this:
> examples :: [Int]
It is enough that a is mentioned in the type of every function so that the
compiler can figure out which instance is required when it is used. In
size you have to pass an a in to figure out what type it is, but in
examples, it is enough to know that it is a list of a's.
On Tue, Sep 10, 2013 at 1:59 PM, Carmine Moleti <[email protected]>wrote:
> 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
>
>
>
> _______________________________________________
> 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/fbc339da/attachment-0001.html>
------------------------------
Message: 2
Date: Tue, 10 Sep 2013 22:11:00 +0100
From: Oscar Benjamin <[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:
<CAHVvXxQ=EFN2=lbrvj7xbowt+3hnzrnjriwwe+jtqxztfo3...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On 10 September 2013 19:06, Brandon Allbery <[email protected]> wrote:
>
> 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.
Initial disclaimer: I'm a total Haskell and functional programming
noob. However I'm well versed in a number of other languages and in
floating point and expend a substantial amount of time focussing on
numerical accuracy.
What do you mean when you say that floating point can't be capture in
a simple functional description? Leaving aside FPU inconsistencies,
hardware failure etc. and assuming some sensible arithmetic (e.g.
IEEE-754) the result of floatadd(A, B) is fully defined for all inputs
A and B. How is that inconsistent with functional programming? I'd
like to understand more about this as when I'm better at Haskell I
expect to use it for at least some floating point computation,
>From my perspective getting floating point computation right is hard.
Proving (or at least reasoning) that an algorithm based on floating
point computation works or has some accuracy is non-trivial and
requires knowledge about the sequence of elementary floating point
operations. I sympathise with the OP in that I consider any compiler
"optimisation" that changes the underlying FPU operations in such a
way that the end result differs should be considered a bug rather than
an optimisation (with the exception of constant folding). But as I
said I'm a total Haskell noob, so I don't yet understand what compiler
optimisations in Haskell really mean or, more importantly, how easily
they can be controlled.
To the OP, if I understand what you're doing correctly then float (or
any binary radix floating point type) is absolutely the wrong thing to
use. If you want to convert from an exact decimal-string
representation of a number to an exact fixed-point integer
representation you should use exact computation in all stages or at
least use a decimal floating point format (I don't know yet if Haskell
has one). Any conversion to binary-float as an intermediary format
risks a (very likely) inexact conversion since binary floating point
format can only represent rational numbers whose denominator (in
lowest terms) is a power of 2. In your case 0.12 is the rational
number 3/25 and 25 is not a power of 2. Consequently when you attempt
to store 0.12 in a binary float you will be getting a float whose
exact value is not 0.12.
I don't know how to conveniently do this in Haskell but in Python we
can easily find the exact decimal representation of the nearest 64-bit
floating point value to 0.12:
$ py -3.3 -c 'from decimal import Decimal; print(Decimal(0.12))'
0.11999999999999999555910790149937383830547332763671875
Multiplying the binary float using the FPU gives us the exact value you wanted:
$ py -3.3 -c 'from decimal import Decimal; print(Decimal(0.12*100))'
12
However the true result of multiplying the nearest binary float to
0.12 by 100 is still slightly less than 12. So if the combined
multiply-by-100-and-truncate operation is performed correctly then you
should get 11.
The appropriate parsing algorithm is straight-forward although I don't
yet know how to do this in Haskell. Split the string on the '.' and
parse both sides as integers. Reject the string if there are not two
digits on the RHS. Then you can multiply the LHS by 100 and add the
RHS. (It's slightly more complex if you need to do negative numbers as
well). It sounds like the Rational type already deals with all this
parsing complexity for you in which case you should use that.
Oscar
------------------------------
Message: 3
Date: Tue, 10 Sep 2013 17:49:36 -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:
<cakfcl4x1sivtatwvqoox81f9dvwhe8hf9q1tbp7ayt58sxg...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
On Tue, Sep 10, 2013 at 5:11 PM, Oscar Benjamin
<[email protected]>wrote:
> What do you mean when you say that floating point can't be capture in
> a simple functional description?
>
*You* try describing the truncation behavior of Intel FPUs (they use 80
bits internally but only store 64, for (double)). "Leaving aside" isn't an
option; it's visible in the languages that use them.
--
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/fe8d31f8/attachment-0001.html>
------------------------------
Message: 4
Date: Tue, 10 Sep 2013 23:14:41 +0100
From: Oscar Benjamin <[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:
<cahvvxxr3mzpk2s8dmmuj1xpzzaf7fr0_pmpjbprc-yzocd0...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On 10 September 2013 22:49, Brandon Allbery <[email protected]> wrote:
> On Tue, Sep 10, 2013 at 5:11 PM, Oscar Benjamin <[email protected]>
> wrote:
>>
>> What do you mean when you say that floating point can't be capture in
>> a simple functional description?
>
> *You* try describing the truncation behavior of Intel FPUs (they use 80 bits
> internally but only store 64, for (double)). "Leaving aside" isn't an
> option; it's visible in the languages that use them.
However, for the same CPU and the same pair of inputs floatadd(A, B)
returns the same result right? The result may differ from one CPU to
another and it doesn't respect associativity etc. but it's still a
well defined function (if no one changes the rounding mode etc. midway
through computation). What is it about functional programming
languages that makes this difficult as you implied earlier?
Oscar
------------------------------
Message: 5
Date: Tue, 10 Sep 2013 19:19:58 -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:
<cakfcl4wp4xpivxktth87qds8tdxbqd3j31sapepejtrpf0w...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
On Tue, Sep 10, 2013 at 6:14 PM, Oscar Benjamin
<[email protected]>wrote:
> On 10 September 2013 22:49, Brandon Allbery <[email protected]> wrote:
> > On Tue, Sep 10, 2013 at 5:11 PM, Oscar Benjamin <
> [email protected]>
> > wrote:
> >>
> >> What do you mean when you say that floating point can't be capture in
> >> a simple functional description?
> >
> > *You* try describing the truncation behavior of Intel FPUs (they use 80
> bits
> > internally but only store 64, for (double)). "Leaving aside" isn't an
> > option; it's visible in the languages that use them.
>
> However, for the same CPU and the same pair of inputs floatadd(A, B)
> returns the same result right? The result may differ from one CPU to
>
In isolation, probably. When combined with other operations, it depends on
optimization and the other operations.
through computation). What is it about functional programming
> languages that makes this difficult as you implied earlier?
Only the expectation differs; programmers in e.g. C generally ignore such
things, although there are obscure compiler options that try to control
what happens. And C doesn't promise much about the behavior anyway. In pure
functional programming, people get used to things behaving in nice
theoretically characterized ways... and then they run into the bit size
limit on Int or the somewhat erratic behavior of Float and Double and
suddenly the nice abstractions fall apart.
--
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/72585e03/attachment.html>
------------------------------
Subject: Digest Footer
_______________________________________________
Beginners mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/beginners
------------------------------
End of Beginners Digest, Vol 63, Issue 15
*****************************************
