Send Beginners mailing list submissions to
beginners@haskell.org
To subscribe or unsubscribe via the World Wide Web, visit
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
or, via email, send a message with subject or body 'help' to
beginners-requ...@haskell.org
You can reach the person managing the list at
beginners-ow...@haskell.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Beginners digest..."
Today's Topics:
1. Re: ghci: inconsistent return values for succ (Frothy Bits)
2. Re: ghci: inconsistent return values for succ
(Kostiantyn Rybnikov)
3. Re: ghci: inconsistent return values for succ (Iustin Pop)
4. Re: ghci: inconsistent return values for succ (Rein Henrichs)
5. Re: ghci: inconsistent return values for succ (Frothy Bits)
----------------------------------------------------------------------
Message: 1
Date: Sun, 18 Oct 2015 08:57:38 -0700
From: Frothy Bits <neuralpanc...@gmail.com>
To: beginners@haskell.org
Subject: Re: [Haskell-beginners] ghci: inconsistent return values for
succ
Message-ID:
<CAHpfcHFHRGvgFZCVXYohasx73MmOG182zCGWZi=5qfpu-9v...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
@ Kostiantyn: Thank you.
Is the behavior I'm seeing actually related to a bug in parsec?
http://stackoverflow.com/questions/29820870/floating-point-numbers-precision-and-parsec
Yes or no, why wouldn't it be the default behavior of ghc to load the
Decimal package?
OTOH, the current default floating point behavior certainly got me thinking
and digging:
http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html
On Sat, Oct 17, 2015 at 7:48 PM, Frothy Bits <neuralpanc...@gmail.com>
wrote:
> @ Dan Stromberg: Thanks, understood.
>
> On Sat, Oct 17, 2015 at 7:17 PM, Frothy Bits <neuralpanc...@gmail.com>
> wrote:
>
>> Greetings,
>>
>> Absolutely brand new to Haskell. Taking ghci v7.10.2 out for a spin, and
>> I find I get inconsistent return values for succ n:
>>
>> ghci> succ 3.14
>> 4.1400000000000001
>>
>> for example instead of the expected 4.14
>>
>> succ 2.14 and 4.14 give the expected results. but succ 2.14 returns
>> 2.1399999999999997. This anomalous behavior runs through the range of
>> n.nn; in the n.01 range, for example, 16.01 and 63.01 return wonky results
>> per above.
>>
>> I tested this on Windows and Linux (various flavors) and I get the same
>> results there and in the interactive test code space on haskell.org.
>>
>> I'm not familiar enough with the language, yet, to go debugging this on
>> my own, but it would seem to be at least a problem with how succ is
>> implemented, if not how values are handled in general.....which could
>> potentially be bad if you were trying to do anything requiring precise
>> calculations....
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.haskell.org/pipermail/beginners/attachments/20151018/a6fbaea2/attachment-0001.html>
------------------------------
Message: 2
Date: Sun, 18 Oct 2015 19:56:51 +0300
From: Kostiantyn Rybnikov <k...@k-bx.com>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <beginners@haskell.org>
Subject: Re: [Haskell-beginners] ghci: inconsistent return values for
succ
Message-ID:
<caabahfr6gddfxqmpaoh6vf2s1ennjyxtkva4igswnbajdg0...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
> Is the behavior I'm seeing actually related to a bug in parsec?
No, I don't think GHC relies on parsec at all.
> Yes or no, why wouldn't it be the default behavior of ghc to load the
Decimal package?
Decimal is very inefficient, because it's implemented as a pair of
numbers: Word8 to describe a position of a dot, and Integer to describe
number itself. E.g., (3.14 :: Decimal) is the same as directly writing
(Decimal 2 314).
Integer, unlike Int and Double, is very inefficient for computation-heavy
code.
Interesting find!
Ghc (its base library) provides Data.Fixed [0] module with similar purposes
to Decimal. Initially I couldn't recommend it, since I thought it has the
same Double-related behavior, but when I digged into it now, I found out
that it's probably a bug (or a "feature") in "succ" implementation:
? succ (3.14 :: Fixed E12)
3.140000000001
? (3.14 :: Fixed E12) + 1
4.140000000000
So, if you don't want to use Decimal, you can just use Data.Fixed (I find
Decimal a bit more elegant though).
[0]: https://hackage.haskell.org/package/base-4.8.1.0/docs/Data-Fixed.html
On Sun, Oct 18, 2015 at 6:57 PM, Frothy Bits <neuralpanc...@gmail.com>
wrote:
> @ Kostiantyn: Thank you.
>
> Is the behavior I'm seeing actually related to a bug in parsec?
>
>
> http://stackoverflow.com/questions/29820870/floating-point-numbers-precision-and-parsec
>
> Yes or no, why wouldn't it be the default behavior of ghc to load the
> Decimal package?
>
> OTOH, the current default floating point behavior certainly got me
> thinking and digging:
>
> http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html
>
>
>
>
>
> On Sat, Oct 17, 2015 at 7:48 PM, Frothy Bits <neuralpanc...@gmail.com>
> wrote:
>
>> @ Dan Stromberg: Thanks, understood.
>>
>> On Sat, Oct 17, 2015 at 7:17 PM, Frothy Bits <neuralpanc...@gmail.com>
>> wrote:
>>
>>> Greetings,
>>>
>>> Absolutely brand new to Haskell. Taking ghci v7.10.2 out for a spin,
>>> and I find I get inconsistent return values for succ n:
>>>
>>> ghci> succ 3.14
>>> 4.1400000000000001
>>>
>>> for example instead of the expected 4.14
>>>
>>> succ 2.14 and 4.14 give the expected results. but succ 2.14 returns
>>> 2.1399999999999997. This anomalous behavior runs through the range of
>>> n.nn; in the n.01 range, for example, 16.01 and 63.01 return wonky results
>>> per above.
>>>
>>> I tested this on Windows and Linux (various flavors) and I get the same
>>> results there and in the interactive test code space on haskell.org.
>>>
>>> I'm not familiar enough with the language, yet, to go debugging this on
>>> my own, but it would seem to be at least a problem with how succ is
>>> implemented, if not how values are handled in general.....which could
>>> potentially be bad if you were trying to do anything requiring precise
>>> calculations....
>>>
>>>
>>
>
> _______________________________________________
> Beginners mailing list
> Beginners@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.haskell.org/pipermail/beginners/attachments/20151018/84caf3e8/attachment-0001.html>
------------------------------
Message: 3
Date: Sun, 18 Oct 2015 19:47:21 +0200
From: Iustin Pop <ius...@k1024.org>
To: Haskell-Beginners <beginners@haskell.org>
Subject: Re: [Haskell-beginners] ghci: inconsistent return values for
succ
Message-ID: <20151018174721.gc24...@teal.hq.k1024.org>
Content-Type: text/plain; charset=us-ascii
On 2015-10-17 19:17:04, Frothy Bits wrote:
> Greetings,
>
> Absolutely brand new to Haskell. Taking ghci v7.10.2 out for a spin, and I
> find I get inconsistent return values for succ n:
>
> ghci> succ 3.14
> 4.1400000000000001
>
> for example instead of the expected 4.14
Separately from the technical implementation of succ for floating point
numbers, does it actually make sense to ask for the successor of a
non-integral value?
There must be some reason why Float and Double implement the Enum class,
but I can't understand in what sense (mathematically) are real numbers
enumerable.
confused,
iustin
------------------------------
Message: 4
Date: Sun, 18 Oct 2015 18:11:10 +0000
From: Rein Henrichs <rein.henri...@gmail.com>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <beginners@haskell.org>
Subject: Re: [Haskell-beginners] ghci: inconsistent return values for
succ
Message-ID:
<cajp6g8wtsk2yt0tmmoaq54cxa+eyykjmnaqcugwfgvcfqle...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
This has nothing to do with Parsec or Decimal. Two things are happening:
First, the type of the literal 3.14 is Fractional a => a. GHCi's extended
default rules [1] pick Double as the default for Fractional. (This is a
good choice.) Second, the closest number to 4.14 that is reresentable as a
Double is 4.1400000000000001. This is an inherent limitation of the
representation used. This effects every use of floating point numbers in
every programming language, and every programmer should understand this.
See [2] for more information.
For an exact result, you can provide a different type for your Fractional
literal that is capable of representing the result exactly:
> succ 3.14 :: Rational
207 % 50
> There must be some reason why Float and Double implement the Enum class,
> but I can't understand in what sense (mathematically) are real numbers
enumerable
You're absolutely right. It is, at best, a kludge and has no mathematical
justification.
[1]
https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/interactive-evaluation.html#extended-default-rules
[2] https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.haskell.org/pipermail/beginners/attachments/20151018/cc823fa2/attachment-0001.html>
------------------------------
Message: 5
Date: Sun, 18 Oct 2015 21:14:57 -0700
From: Frothy Bits <neuralpanc...@gmail.com>
To: beginners@haskell.org
Subject: Re: [Haskell-beginners] ghci: inconsistent return values for
succ
Message-ID:
<cahpfchfkqsj3haaotxnacmegtzgr0d5r2fxpbcvh+1g9f3x...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
@ Kostiantyn: Thank you again for the links to Decimal and Data.Fixed
@ Iustin: You're absolutely correct, I was abusing succ. I blame myself.
@ Rein: Thank you, I'd previously shared the goldberg paper; it's
illuminating.
Fwiw, prior to adventures with succ, I'd noticed that simple operations on
certain simple real numbers would give "exciting" results. (Undoubtedly, I
should have just gone with that instead of posting about succ; apologies
again for confusing Iustin.)
ghci> map (+ 0.01)[0.01,0.02 .. 1.00]
for example, gave me a nice list of visually stimulating values for the
reasons Rein and Kostiantyn pointed out. With succ, I wondered what I
would see if I did something "wrong." My assumption was that it would
flail and give me an error message, something along the lines of "Fool,
that is not the proper way to succ. Go play with natural numbers." That
I'd get occasionally expected values with either the above or succ
was.....peculiar, until reading Kostiantyn's replies and finding and
reading the Goldberg paper, not to mention having a "Forth moment" and
remembering scaled integer......
I (foolishly or not) made the assumption that Haskell would do something
different with floats "out of the box." I do realize the same issues are
inherent in other languages, but I wondered if it might be "smart,"
recognize I was calculating with real numbers and automagically either load
what I needed or point me in that direction. That said, I really
appreciate Rein's reply and recognize that picking Double for the extended
default rules is "a good choice."
Anyway, after loading Data.Fixed, this produces reasonable output:
ghci> map (+ (0.01 :: Fixed E2)) [0.01,0.02 .. 1.01]
Back to reading and learning by cutting myself. Thanks again all.
On Sun, Oct 18, 2015 at 8:57 AM, Frothy Bits <neuralpanc...@gmail.com>
wrote:
> @ Kostiantyn: Thank you.
>
> Is the behavior I'm seeing actually related to a bug in parsec?
>
>
> http://stackoverflow.com/questions/29820870/floating-point-numbers-precision-and-parsec
>
> Yes or no, why wouldn't it be the default behavior of ghc to load the
> Decimal package?
>
> OTOH, the current default floating point behavior certainly got me
> thinking and digging:
>
> http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html
>
>
>
>
>
> On Sat, Oct 17, 2015 at 7:48 PM, Frothy Bits <neuralpanc...@gmail.com>
> wrote:
>
>> @ Dan Stromberg: Thanks, understood.
>>
>> On Sat, Oct 17, 2015 at 7:17 PM, Frothy Bits <neuralpanc...@gmail.com>
>> wrote:
>>
>>> Greetings,
>>>
>>> Absolutely brand new to Haskell. Taking ghci v7.10.2 out for a spin,
>>> and I find I get inconsistent return values for succ n:
>>>
>>> ghci> succ 3.14
>>> 4.1400000000000001
>>>
>>> for example instead of the expected 4.14
>>>
>>> succ 2.14 and 4.14 give the expected results. but succ 2.14 returns
>>> 2.1399999999999997. This anomalous behavior runs through the range of
>>> n.nn; in the n.01 range, for example, 16.01 and 63.01 return wonky results
>>> per above.
>>>
>>> I tested this on Windows and Linux (various flavors) and I get the same
>>> results there and in the interactive test code space on haskell.org.
>>>
>>> I'm not familiar enough with the language, yet, to go debugging this on
>>> my own, but it would seem to be at least a problem with how succ is
>>> implemented, if not how values are handled in general.....which could
>>> potentially be bad if you were trying to do anything requiring precise
>>> calculations....
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.haskell.org/pipermail/beginners/attachments/20151018/7a0ff68c/attachment.html>
------------------------------
Subject: Digest Footer
_______________________________________________
Beginners mailing list
Beginners@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
------------------------------
End of Beginners Digest, Vol 88, Issue 15
*****************************************
