My understanding is that it was intended to support enumerations where you write the exact end point, like [1.0, 1.1 .. 2.3]

Because of floating point quirks, this could end up generating a value close to 2.3 that's slightly larger than the value close to 2.3 constructed by directly converting the decimal expression into a floating point number. You need to allow some "slack" in the upper bound to guarantee a value close to the written end point appears in the list. Increasing the bound by half a delta means there will be something close to 2.3 in the list, and shouldn't go far enough to include the next greater element generated.

I suppose by that reasoning you're "not supposed" to use enumerations like [1.0, 3 .. 4], because 4 isn't the idealised mathematical endpoint of the sequence.

On October 20, 2016 6:24:29 AM GMT+11:00, Brandon Allbery <allbery.b@gmail.com> wrote:

On Wed, Oct 19, 2016 at 8:13 AM, Bence Kodaj <bence.kodaj@gmail.com> wrote:
Does anybody happen to know why [1.0, 3 ..4 ] is [1.0, 3.0, 5.0] ?

Nobody seems to know, aside from "that's what the Libraries part of the Report says". You'd probably have to find the committee that added it to the Report (good luck...) to learn their logic. (The quirks of FP arithmetic don't seem to be involved, since the overshoot is overkill for that.)

--
brandon s allbery kf8nh sine nomine associates
allbery.b@gmail.com ballbery@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.