How to improve the accuracy of floating point calculation?

older
Re: [Haskell-beginners] too lazy...

yi lu

5 Feb 2013 5 Feb '13

5:41 p.m.

Hi, I found that in ghci, I input [0.1,0.2..2] and run, I get a result of [0.1,0.2,0.30000000000000004,0.4000000000000001,0.5000000000000001,0.6000000000000001,0.7000000000000001,0.8,0.9,1.0,1.1,1.2000000000000002,1.3000000000000003,1.4000000000000004,1.5000000000000004,1.6000000000000005,1.7000000000000006,1.8000000000000007,1.9000000000000008,2.000000000000001] But, as you know, it is not the exact answer. So, I wonder if there is something I can do to achieve a better performance and get [0.1,0.2,0.3,0.4..] as the result. Thanks.

Attachments:

attachment.html (text/html — 834 bytes)

Show replies by date

Brandon Allbery

5 Feb 5 Feb

5:50 p.m.

New subject: How to improve the accuracy of floating point calculation?

On Tue, Feb 5, 2013 at 5:41 PM, yi lu wrote:

...

I found that in ghci, I input [0.1,0.2..2] and run, I get a result of

[0.1,0.2,0.30000000000000004,0.4000000000000001,0.5000000000000001,0.6000000000000001,0.7000000000000001,0.8,0.9,1.0,1.1,1.2000000000000002,1.3000000000000003,1.4000000000000004,1.5000000000000004,1.6000000000000005,1.7000000000000006,1.8000000000000007,1.9000000000000008,2.000000000000001]

But, as you know, it is not the exact answer.

So, I wonder if there is something I can do to achieve a better performance and get [0.1,0.2,0.3,0.4..] as the result.

Welcome to the world of floating point numbers. Perfect accuracy is not possible; the CReal type from the "numbers" package may handle cases you care about, or may not. (Other languages often use output formats that can largely hide the errors, but they're still there and will eventually accumulate into visibility.) -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

yi lu

6:04 p.m.

New subject: How to improve the accuracy of floating point calculation?

Thanks! I'll try CReal. But can I set *significant figures **myself?* On Wed, Feb 6, 2013 at 6:50 AM, Brandon Allbery wrote:

...

On Tue, Feb 5, 2013 at 5:41 PM, yi lu wrote:

...
I found that in ghci, I input [0.1,0.2..2] and run, I get a result of

[0.1,0.2,0.30000000000000004,0.4000000000000001,0.5000000000000001,0.6000000000000001,0.7000000000000001,0.8,0.9,1.0,1.1,1.2000000000000002,1.3000000000000003,1.4000000000000004,1.5000000000000004,1.6000000000000005,1.7000000000000006,1.8000000000000007,1.9000000000000008,2.000000000000001]

But, as you know, it is not the exact answer.

So, I wonder if there is something I can do to achieve a better performance and get [0.1,0.2,0.3,0.4..] as the result.

Welcome to the world of floating point numbers. Perfect accuracy is not possible; the CReal type from the "numbers" package may handle cases you care about, or may not. (Other languages often use output formats that can largely hide the errors, but they're still there and will eventually accumulate into visibility.)

-- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners

John Wiegley

6 Feb 6 Feb

3:31 a.m.

New subject: How to improve the accuracy of floating point calculation?

...

...
...
...
...
yi lu writes:

...

I'll try CReal.

Also try the 'numbers' library. -- John Wiegley FP Complete Haskell tools, training and consulting http://fpcomplete.com johnw on #haskell/irc.freenode.net

Brandon Allbery

9:03 a.m.

New subject: How to improve the accuracy of floating point calculation?

On Tue, Feb 5, 2013 at 6:04 PM, yi lu wrote:

...

Thanks! I'll try CReal. But can I set *significant figures **myself?*

You can't change ghci's output format, but you can do your own output instead of relying on ghci's. http://hackage.haskell.org/packages/archive/base/latest/doc/html/Text-Printf... be of interest, or doing it manually with scaling and Prelude.round. -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

Hollister Herhold

5 Feb 5 Feb

5:52 p.m.

New subject: How to improve the accuracy of floating point calculation?

The issue is that floating point numbers are really not precise. This is not inherent to Haskell in particular - any given computer (and programming language) is subject to lack of precision for floating point numbers. You can take a look at the wikipedia entry (http://en.wikipedia.org/wiki/Floating_point_numbers). If you want a really "meaty" description of the issues involved, take a look at Knuth's "Seminumerical Algorithms". On Feb 5, 2013, at 4:41 PM, yi lu wrote:

...

Hi,

I found that in ghci, I input [0.1,0.2..2] and run, I get a result of

[0.1,0.2,0.30000000000000004,0.4000000000000001,0.5000000000000001,0.6000000000000001,0.7000000000000001,0.8,0.9,1.0,1.1,1.2000000000000002,1.3000000000000003,1.4000000000000004,1.5000000000000004,1.6000000000000005,1.7000000000000006,1.8000000000000007,1.9000000000000008,2.000000000000001]

But, as you know, it is not the exact answer.

So, I wonder if there is something I can do to achieve a better performance and get [0.1,0.2,0.3,0.4..] as the result.

Thanks. _______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners

David McBride

5:55 p.m.

New subject: How to improve the accuracy of floating point calculation?

Use rationals and then convert to float. Ie:

...

[0.1::Rational,0.2..2] [1 % 10,1 % 5,3 % 10,2 % 5,1 % 2,3 % 5,7 % 10,4 % 5,9 % 10,1 % 1,11 % 10,6 % 5,13 % 10,7 % 5,3 % 2,8 % 5,17 % 10,9 % 5,19 % 10,2 % 1]

Then to get something useful from it:

...

map fromRational $ [0.1::Rational,0.2..2] [0.1,0.2,0.3,0.4,0.5,0.6,0.7,0.8,0.9,1.0,1.1,1.2,1.3,1.4,1.5,1.6,1.7,1.8,1.9,2.0]

On Tue, Feb 5, 2013 at 5:41 PM, yi lu wrote:

...

Hi,

I found that in ghci, I input [0.1,0.2..2] and run, I get a result of

[0.1,0.2,0.30000000000000004,0.4000000000000001,0.5000000000000001,0.6000000000000001,0.7000000000000001,0.8,0.9,1.0,1.1,1.2000000000000002,1.3000000000000003,1.4000000000000004,1.5000000000000004,1.6000000000000005,1.7000000000000006,1.8000000000000007,1.9000000000000008,2.000000000000001]

But, as you know, it is not the exact answer.

So, I wonder if there is something I can do to achieve a better performance and get [0.1,0.2,0.3,0.4..] as the result.

Thanks.

_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners

KC

6:08 p.m.

New subject: How to improve the accuracy of floating point calculation?

0.1 cannot be represented exactly in floating point. 0.5 can be represented exactly. Why? On Tue, Feb 5, 2013 at 2:41 PM, yi lu wrote:

...

Hi,

I found that in ghci, I input [0.1,0.2..2] and run, I get a result of

[0.1,0.2,0.30000000000000004,0.4000000000000001,0.5000000000000001,0.6000000000000001,0.7000000000000001,0.8,0.9,1.0,1.1,1.2000000000000002,1.3000000000000003,1.4000000000000004,1.5000000000000004,1.6000000000000005,1.7000000000000006,1.8000000000000007,1.9000000000000008,2.000000000000001]

But, as you know, it is not the exact answer.

So, I wonder if there is something I can do to achieve a better performance and get [0.1,0.2,0.3,0.4..] as the result.

Thanks.

_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners

-- -- Regards, KC

Patrick Mylund Nielsen

6:24 p.m.

New subject: How to improve the accuracy of floating point calculation?

http://floating-point-gui.de/ http://floating-point-gui.de/formats/fp/ http://en.wikipedia.org/wiki/Floating_point#Accuracy_problems On Wed, Feb 6, 2013 at 12:08 AM, KC wrote:

...

0.1 cannot be represented exactly in floating point.

0.5 can be represented exactly. Why?

On Tue, Feb 5, 2013 at 2:41 PM, yi lu wrote:

...
Hi,

I found that in ghci, I input [0.1,0.2..2] and run, I get a result of

[0.1,0.2,0.30000000000000004,0.4000000000000001,0.5000000000000001,0.6000000000000001,0.7000000000000001,0.8,0.9,1.0,1.1,1.2000000000000002,1.3000000000000003,1.4000000000000004,1.5000000000000004,1.6000000000000005,1.7000000000000006,1.8000000000000007,1.9000000000000008,2.000000000000001]

...
But, as you know, it is not the exact answer.

So, I wonder if there is something I can do to achieve a better

performance

...
and get [0.1,0.2,0.3,0.4..] as the result.

Thanks.

_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners

-- -- Regards, KC

_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners

Darren Grant

7:12 p.m.

New subject: How to improve the accuracy of floating point calculation?

I'm not sure how CReal implements its values, but IEEE754 also supports decimal formats preferred for accuracy in many applications. Take a look: http://en.wikipedia.org/wiki/IEEE_floating_point Cheers, d On Tue, Feb 5, 2013 at 3:24 PM, Patrick Mylund Nielsen < haskell@patrickmylund.com> wrote:

...

http://floating-point-gui.de/ http://floating-point-gui.de/formats/fp/

http://en.wikipedia.org/wiki/Floating_point#Accuracy_problems

On Wed, Feb 6, 2013 at 12:08 AM, KC wrote:

...
0.1 cannot be represented exactly in floating point.

0.5 can be represented exactly. Why?

On Tue, Feb 5, 2013 at 2:41 PM, yi lu wrote:

...
Hi,

I found that in ghci, I input [0.1,0.2..2] and run, I get a result of

[0.1,0.2,0.30000000000000004,0.4000000000000001,0.5000000000000001,0.6000000000000001,0.7000000000000001,0.8,0.9,1.0,1.1,1.2000000000000002,1.3000000000000003,1.4000000000000004,1.5000000000000004,1.6000000000000005,1.7000000000000006,1.8000000000000007,1.9000000000000008,2.000000000000001]

...
But, as you know, it is not the exact answer.

So, I wonder if there is something I can do to achieve a better

performance

...
and get [0.1,0.2,0.3,0.4..] as the result.

Thanks.

_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners

-- -- Regards, KC

_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners

_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners

Mateusz Kowalczyk

7:47 p.m.

New subject: How to improve the accuracy of floating point calculation?

I thought that KC was asking why is 0.5 not displayed as 0.5 when it's supported by the IEEE754. Even if that wasn't question, it is my question now. IEEE754 is capable of representing 0.5 with perfect precision; in fact, it would be `00111111000000000000000000000000'. My question is why [0.1, 0.2 .. 1.0] comes up with an imprecise midpoint: [0.1,0.2,0.30000000000000004,0.4000000000000001,0.5000000000000001,0.6000000000000001,0.7000000000000001,0.8,0.9,1.0] My initial guess is that the expansion is done by working out the difference between the first two elements and using that to generate the rest. This also makes me question why 0.1 is shown properly when it can't be represented precisely in IEEE754. Quickly rolling own list generation function: *Main> let f x y = x : f y (y + y - x) *Main> take 10 $ f 0.1 0.2 [0.1,0.2,0.30000000000000004,0.4000000000000001,0.5000000000000001,0.6000000000000001,0.7000000000000001,0.8,0.9,1.0] reveals the same result as the short-hand which would imply that it's exactly what it's doing (for the simple case). My question for why can 0.1 be shown properly still stands in this case. On 06/02/13 00:12, Darren Grant wrote:

...

I'm not sure how CReal implements its values, but IEEE754 also supports decimal formats preferred for accuracy in many applications. Take a look:

http://en.wikipedia.org/wiki/IEEE_floating_point

Cheers, d

On Tue, Feb 5, 2013 at 3:24 PM, Patrick Mylund Nielsen mailto:haskell@patrickmylund.com> wrote:

http://floating-point-gui.de/ http://floating-point-gui.de/formats/fp/

http://en.wikipedia.org/wiki/Floating_point#Accuracy_problems

On Wed, Feb 6, 2013 at 12:08 AM, KC mailto:kc1956@gmail.com> wrote:

0.1 cannot be represented exactly in floating point.

0.5 can be represented exactly. Why?

On Tue, Feb 5, 2013 at 2:41 PM, yi lu mailto:zhiwudazhanjiangshi@gmail.com> wrote: > Hi, > > I found that in ghci, I input > [0.1,0.2..2] > and run, I get a result of > > [0.1,0.2,0.30000000000000004,0.4000000000000001,0.5000000000000001,0.6000000000000001,0.7000000000000001,0.8,0.9,1.0,1.1,1.2000000000000002,1.3000000000000003,1.4000000000000004,1.5000000000000004,1.6000000000000005,1.7000000000000006,1.8000000000000007,1.9000000000000008,2.000000000000001] > > But, as you know, it is not the exact answer. > > So, I wonder if there is something I can do to achieve a better performance > and get [0.1,0.2,0.3,0.4..] as the result. > > Thanks. > > _______________________________________________ > Beginners mailing list > Beginners@haskell.org mailto:Beginners@haskell.org > http://www.haskell.org/mailman/listinfo/beginners >

-- -- Regards, KC

_______________________________________________ Beginners mailing list Beginners@haskell.org mailto:Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners

_______________________________________________ Beginners mailing list Beginners@haskell.org mailto:Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners

_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners

Mateusz Kowalczyk

8:07 p.m.

New subject: How to improve the accuracy of floating point calculation?

We just figured it out over here. The short version is that the 0.1 and 0.2 just happen to round pretty well (to what looks perfect to a human) while other figures don't. This can be easily represented by forcing a [Float] type for lower precision as opposed to the default double precision: *Main> [0.1, 0.2 .. 1] :: [Float] [0.1,0.2,0.3,0.40000004,0.50000006,0.6000001,0.7000001,0.80000013,0.90000015,1.0000002] Above we can easily see that with a float the errors compound so much that the numbers no longer round to a human-friendly representation. This can also be shown with doubles: the 0.1 was displayed as 0.1 because it just happened to be fairly precise. Start compounding errors early enough and it no longer rounds so nicely: [-0.5,-0.4,-0.30000000000000004,-0.20000000000000007,-0.10000000000000009,-1.1102230246251565e-16,9.999999999999987e-2,0.19999999999999984,0.2999999999999998,0.3999999999999998,0.4999999999999998] You can see just how much precision we lost at mid-point by looking at what should be 0. Thanks On 06/02/13 00:47, Mateusz Kowalczyk wrote:

...

I thought that KC was asking why is 0.5 not displayed as 0.5 when it's supported by the IEEE754. Even if that wasn't question, it is my question now.

IEEE754 is capable of representing 0.5 with perfect precision; in fact, it would be `00111111000000000000000000000000'.

My question is why [0.1, 0.2 .. 1.0] comes up with an imprecise midpoint: [0.1,0.2,0.30000000000000004,0.4000000000000001,0.5000000000000001,0.6000000000000001,0.7000000000000001,0.8,0.9,1.0]

My initial guess is that the expansion is done by working out the difference between the first two elements and using that to generate the rest. This also makes me question why 0.1 is shown properly when it can't be represented precisely in IEEE754. Quickly rolling own list generation function:

*Main> let f x y = x : f y (y + y - x) *Main> take 10 $ f 0.1 0.2 [0.1,0.2,0.30000000000000004,0.4000000000000001,0.5000000000000001,0.6000000000000001,0.7000000000000001,0.8,0.9,1.0]

reveals the same result as the short-hand which would imply that it's exactly what it's doing (for the simple case). My question for why can 0.1 be shown properly still stands in this case.

On 06/02/13 00:12, Darren Grant wrote:

...
I'm not sure how CReal implements its values, but IEEE754 also supports decimal formats preferred for accuracy in many applications. Take a look:

http://en.wikipedia.org/wiki/IEEE_floating_point

Cheers, d

On Tue, Feb 5, 2013 at 3:24 PM, Patrick Mylund Nielsen mailto:haskell@patrickmylund.com> wrote:

http://floating-point-gui.de/ http://floating-point-gui.de/formats/fp/

http://en.wikipedia.org/wiki/Floating_point#Accuracy_problems

On Wed, Feb 6, 2013 at 12:08 AM, KC mailto:kc1956@gmail.com> wrote:

0.1 cannot be represented exactly in floating point.

0.5 can be represented exactly. Why?

On Tue, Feb 5, 2013 at 2:41 PM, yi lu mailto:zhiwudazhanjiangshi@gmail.com> wrote: > Hi, > > I found that in ghci, I input > [0.1,0.2..2] > and run, I get a result of > > [0.1,0.2,0.30000000000000004,0.4000000000000001,0.5000000000000001,0.6000000000000001,0.7000000000000001,0.8,0.9,1.0,1.1,1.2000000000000002,1.3000000000000003,1.4000000000000004,1.5000000000000004,1.6000000000000005,1.7000000000000006,1.8000000000000007,1.9000000000000008,2.000000000000001] > > But, as you know, it is not the exact answer. > > So, I wonder if there is something I can do to achieve a better performance > and get [0.1,0.2,0.3,0.4..] as the result. > > Thanks. > > _______________________________________________ > Beginners mailing list > Beginners@haskell.org mailto:Beginners@haskell.org > http://www.haskell.org/mailman/listinfo/beginners >

-- -- Regards, KC

_______________________________________________ Beginners mailing list Beginners@haskell.org mailto:Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners

_______________________________________________ Beginners mailing list Beginners@haskell.org mailto:Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners

_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners

_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners

Darren Grant

8:50 p.m.

New subject: How to improve the accuracy of floating point calculation?

It's a pathological situation that arises from the way enumFromThenTo is defined for floating point values. Does anyone know why the specific implementation isn't more accurate? In simple cases you can sometimes convert an integer range to desired floating point range to avoid cumulative precision errors. Cheers, d On Tue, Feb 5, 2013 at 5:07 PM, Mateusz Kowalczyk wrote:

...

We just figured it out over here. The short version is that the 0.1 and 0.2 just happen to round pretty well (to what looks perfect to a human) while other figures don't. This can be easily represented by forcing a [Float] type for lower precision as opposed to the default double precision: *Main> [0.1, 0.2 .. 1] :: [Float]

[0.1,0.2,0.3,0.40000004,0.50000006,0.6000001,0.7000001,0.80000013,0.90000015,1.0000002]

Above we can easily see that with a float the errors compound so much that the numbers no longer round to a human-friendly representation.

This can also be shown with doubles: the 0.1 was displayed as 0.1 because it just happened to be fairly precise. Start compounding errors early enough and it no longer rounds so nicely:

[-0.5,-0.4,-0.30000000000000004,-0.20000000000000007,-0.10000000000000009,-1.1102230246251565e-16,9.999999999999987e-2,0.19999999999999984,0.2999999999999998,0.3999999999999998,0.4999999999999998]

You can see just how much precision we lost at mid-point by looking at what should be 0.

Thanks

On 06/02/13 00:47, Mateusz Kowalczyk wrote:

...
I thought that KC was asking why is 0.5 not displayed as 0.5 when it's supported by the IEEE754. Even if that wasn't question, it is my question now.

IEEE754 is capable of representing 0.5 with perfect precision; in fact, it would be `00111111000000000000000000000000'.

My question is why [0.1, 0.2 .. 1.0] comes up with an imprecise midpoint:

[0.1,0.2,0.30000000000000004,0.4000000000000001,0.5000000000000001,0.6000000000000001,0.7000000000000001,0.8,0.9,1.0]

...
My initial guess is that the expansion is done by working out the difference between the first two elements and using that to generate the rest. This also makes me question why 0.1 is shown properly when it can't be represented precisely in IEEE754. Quickly rolling own list generation function:

*Main> let f x y = x : f y (y + y - x) *Main> take 10 $ f 0.1 0.2

[0.1,0.2,0.30000000000000004,0.4000000000000001,0.5000000000000001,0.6000000000000001,0.7000000000000001,0.8,0.9,1.0]

...
reveals the same result as the short-hand which would imply that it's exactly what it's doing (for the simple case). My question for why can 0.1 be shown properly still stands in this case.

On 06/02/13 00:12, Darren Grant wrote:

...
I'm not sure how CReal implements its values, but IEEE754 also supports decimal formats preferred for accuracy in many applications. Take a

look:

...
...
http://en.wikipedia.org/wiki/IEEE_floating_point

Cheers, d

On Tue, Feb 5, 2013 at 3:24 PM, Patrick Mylund Nielsen mailto:haskell@patrickmylund.com> wrote:

http://floating-point-gui.de/ http://floating-point-gui.de/formats/fp/

http://en.wikipedia.org/wiki/Floating_point#Accuracy_problems

On Wed, Feb 6, 2013 at 12:08 AM, KC mailto:kc1956@gmail.com> wrote:

0.1 cannot be represented exactly in floating point.

0.5 can be represented exactly. Why?

On Tue, Feb 5, 2013 at 2:41 PM, yi lu mailto:zhiwudazhanjiangshi@gmail.com> wrote: > Hi, > > I found that in ghci, I input > [0.1,0.2..2] > and run, I get a result of > >

[0.1,0.2,0.30000000000000004,0.4000000000000001,0.5000000000000001,0.6000000000000001,0.7000000000000001,0.8,0.9,1.0,1.1,1.2000000000000002,1.3000000000000003,1.4000000000000004,1.5000000000000004,1.6000000000000005,1.7000000000000006,1.8000000000000007,1.9000000000000008,2.000000000000001]

...
> > But, as you know, it is not the exact answer. > > So, I wonder if there is something I can do to achieve a better performance > and get [0.1,0.2,0.3,0.4..] as the result. > > Thanks. > > _______________________________________________ > Beginners mailing list > Beginners@haskell.org mailto:Beginners@haskell.org > http://www.haskell.org/mailman/listinfo/beginners >

-- -- Regards, KC

_______________________________________________ Beginners mailing list Beginners@haskell.org mailto:Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners

_______________________________________________ Beginners mailing list Beginners@haskell.org mailto:Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners

_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners

_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners

_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners

KC

8:58 p.m.

New subject: How to improve the accuracy of floating point calculation?

I should have been more precise; I truncated my own remarks. 0.1 cannot be represented exactly in floating point because it is not a power of two; whereas, 0.5 is 1/2 = 2^(-1). Floating point stores its mantissa as binary bits. On Tue, Feb 5, 2013 at 4:47 PM, Mateusz Kowalczyk wrote:

...

I thought that KC was asking why is 0.5 not displayed as 0.5 when it's supported by the IEEE754. Even if that wasn't question, it is my question now.

IEEE754 is capable of representing 0.5 with perfect precision; in fact, it would be `00111111000000000000000000000000'.

My question is why [0.1, 0.2 .. 1.0] comes up with an imprecise midpoint: [0.1,0.2,0.30000000000000004,0.4000000000000001,0.5000000000000001,0.6000000000000001,0.7000000000000001,0.8,0.9,1.0]

_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners

-- -- Regards, KC

4486

Age (days ago)

4487

Last active (days ago)

List overview

Download

13 comments

9 participants

participants (9)

Brandon Allbery
Darren Grant
David McBride
Hollister Herhold
John Wiegley
KC
Mateusz Kowalczyk
Patrick Mylund Nielsen
yi lu