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) (Carmine Moleti)
2. Re: truncate results depend on strict/lazy (Oscar Benjamin)
----------------------------------------------------------------------
Message: 1
Date: Wed, 11 Sep 2013 06:38:41 +0000 (UTC)
From: Carmine Moleti <[email protected]>
To: [email protected]
Subject: Re: [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=utf-8
David McBride <toad3k <at> gmail.com> writes:
> 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.
Makes sense now. Thanks again for your help sir.
Regards,
Carmine
------------------------------
Message: 2
Date: Wed, 11 Sep 2013 11:41: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:
<CAHVvXxRLqwhSdwtDH9_HYt5v5uQiXuXA8y=hwsjb9emzzu0...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On 11 September 2013 00:19, Brandon Allbery <[email protected]> wrote:
> 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.
Well that depends what you mean. floatadd(A, floatadd(B, C)) is also a
well defined function. It just happens that it is not equivalent to
floatadd(floatadd(A, B), C). But the same is true for most functions.
If the compiler tries to optimise by assuming that e.g. (a+b)+c is
equivalent to a+(b+c) for floats then this is not really an
optimisation but rather a semantic change. If those kind of
optimisations are occurring beneath your feet then it becomes pretty
much impossible to reason about the accuracy of higher-level code.
>> 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.
It's true that straight-forward C code is very much subject to
problems with regard to compiler optimisation and that most C
programmers don't care. However as of C99 the C standards are
integrated with IEEE-754 meaning that if you do care about these
things then it is possible to control them (without resorting to
Fortran!). Does Haskell have language/compiler features that can
protect FP operations from unsafe optimisation (or from any
optimisation)?
Oscar
------------------------------
Subject: Digest Footer
_______________________________________________
Beginners mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/beginners
------------------------------
End of Beginners Digest, Vol 63, Issue 16
*****************************************
