<div dir="ltr">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?<div><br></div><div style>
In simple cases you can sometimes convert an integer range to desired floating point range to avoid cumulative precision errors.</div><div style><br></div><div style>Cheers,</div><div style>d</div><div style><br></div></div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Feb 5, 2013 at 5:07 PM, Mateusz Kowalczyk <span dir="ltr"><<a href="mailto:fuuzetsu@fuuzetsu.co.uk" target="_blank">fuuzetsu@fuuzetsu.co.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">We just figured it out over here. The short version is that the 0.1 and<br>
0.2 just happen to round pretty well (to what looks perfect to a human)<br>
while other figures don't. This can be easily represented by forcing a<br>
[Float] type for lower precision as opposed to the default double precision:<br>
*Main> [0.1, 0.2 .. 1] :: [Float]<br>
[0.1,0.2,0.3,0.40000004,0.50000006,0.6000001,0.7000001,0.80000013,0.90000015,1.0000002]<br>
<br>
Above we can easily see that with a float the errors compound so much<br>
that the numbers no longer round to a human-friendly representation.<br>
<br>
This can also be shown with doubles: the 0.1 was displayed as 0.1<br>
because it just happened to be fairly precise. Start compounding errors<br>
early enough and it no longer rounds so nicely:<br>
[-0.5,-0.4,-0.30000000000000004,-0.20000000000000007,-0.10000000000000009,-1.1102230246251565e-16,9.999999999999987e-2,0.19999999999999984,0.2999999999999998,0.3999999999999998,0.4999999999999998]<br>
<br>
You can see just how much precision we lost at mid-point by looking at<br>
what should be 0.<br>
<br>
Thanks<br>
<div class="HOEnZb"><div class="h5"><br>
On 06/02/13 00:47, Mateusz Kowalczyk wrote:<br>
> I thought that KC was asking why is 0.5 not displayed as 0.5 when it's<br>
> supported by the IEEE754. Even if that wasn't question, it is my<br>
> question now.<br>
><br>
> IEEE754 is capable of representing 0.5 with perfect precision; in fact,<br>
> it would be `00111111000000000000000000000000'.<br>
><br>
> My question is why [0.1, 0.2 .. 1.0] comes up with an imprecise<br>
> midpoint:<br>
> [0.1,0.2,0.30000000000000004,0.4000000000000001,0.5000000000000001,0.6000000000000001,0.7000000000000001,0.8,0.9,1.0]<br>
><br>
> My initial guess is that the expansion is done by working out the<br>
> difference between the first two elements and using that to generate the<br>
> rest. This also makes me question why 0.1 is shown properly when it<br>
> can't be represented precisely in IEEE754. Quickly rolling own list<br>
> generation function:<br>
><br>
> *Main> let f x y = x : f y (y + y - x)<br>
> *Main> take 10 $ f 0.1 0.2<br>
> [0.1,0.2,0.30000000000000004,0.4000000000000001,0.5000000000000001,0.6000000000000001,0.7000000000000001,0.8,0.9,1.0]<br>
><br>
> reveals the same result as the short-hand which would imply that it's<br>
> exactly what it's doing (for the simple case). My question for why can<br>
> 0.1 be shown properly still stands in this case.<br>
><br>
> On 06/02/13 00:12, Darren Grant wrote:<br>
>> I'm not sure how CReal implements its values, but IEEE754 also supports<br>
>> decimal formats preferred for accuracy in many applications. Take a look:<br>
>><br>
>> <a href="http://en.wikipedia.org/wiki/IEEE_floating_point" target="_blank">http://en.wikipedia.org/wiki/IEEE_floating_point</a><br>
>><br>
>><br>
>> Cheers,<br>
>> d<br>
>><br>
>><br>
>><br>
>><br>
>> On Tue, Feb 5, 2013 at 3:24 PM, Patrick Mylund Nielsen<br>
>> <<a href="mailto:haskell@patrickmylund.com">haskell@patrickmylund.com</a> <mailto:<a href="mailto:haskell@patrickmylund.com">haskell@patrickmylund.com</a>>> wrote:<br>
>><br>
>> <a href="http://floating-point-gui.de/" target="_blank">http://floating-point-gui.de/</a><br>
>> <a href="http://floating-point-gui.de/formats/fp/" target="_blank">http://floating-point-gui.de/formats/fp/</a><br>
>><br>
>> <a href="http://en.wikipedia.org/wiki/Floating_point#Accuracy_problems" target="_blank">http://en.wikipedia.org/wiki/Floating_point#Accuracy_problems</a><br>
>><br>
>><br>
>> On Wed, Feb 6, 2013 at 12:08 AM, KC <<a href="mailto:kc1956@gmail.com">kc1956@gmail.com</a><br>
>> <mailto:<a href="mailto:kc1956@gmail.com">kc1956@gmail.com</a>>> wrote:<br>
>><br>
>> 0.1 cannot be represented exactly in floating point.<br>
>><br>
>> 0.5 can be represented exactly. Why?<br>
>><br>
>><br>
>> On Tue, Feb 5, 2013 at 2:41 PM, yi lu<br>
>> <<a href="mailto:zhiwudazhanjiangshi@gmail.com">zhiwudazhanjiangshi@gmail.com</a><br>
>> <mailto:<a href="mailto:zhiwudazhanjiangshi@gmail.com">zhiwudazhanjiangshi@gmail.com</a>>> wrote:<br>
>> > Hi,<br>
>> ><br>
>> > I found that in ghci, I input<br>
>> > [0.1,0.2..2]<br>
>> > and run, I get a result of<br>
>> ><br>
>> ><br>
>> [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]<br>
>> ><br>
>> > But, as you know, it is not the exact answer.<br>
>> ><br>
>> > So, I wonder if there is something I can do to achieve a<br>
>> better performance<br>
>> > and get [0.1,0.2,0.3,0.4..] as the result.<br>
>> ><br>
>> > Thanks.<br>
>> ><br>
>> > _______________________________________________<br>
>> > Beginners mailing list<br>
>> > <a href="mailto:Beginners@haskell.org">Beginners@haskell.org</a> <mailto:<a href="mailto:Beginners@haskell.org">Beginners@haskell.org</a>><br>
>> > <a href="http://www.haskell.org/mailman/listinfo/beginners" target="_blank">http://www.haskell.org/mailman/listinfo/beginners</a><br>
>> ><br>
>><br>
>><br>
>><br>
>> --<br>
>> --<br>
>> Regards,<br>
>> KC<br>
>><br>
>> _______________________________________________<br>
>> Beginners mailing list<br>
>> <a href="mailto:Beginners@haskell.org">Beginners@haskell.org</a> <mailto:<a href="mailto:Beginners@haskell.org">Beginners@haskell.org</a>><br>
>> <a href="http://www.haskell.org/mailman/listinfo/beginners" target="_blank">http://www.haskell.org/mailman/listinfo/beginners</a><br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> Beginners mailing list<br>
>> <a href="mailto:Beginners@haskell.org">Beginners@haskell.org</a> <mailto:<a href="mailto:Beginners@haskell.org">Beginners@haskell.org</a>><br>
>> <a href="http://www.haskell.org/mailman/listinfo/beginners" target="_blank">http://www.haskell.org/mailman/listinfo/beginners</a><br>
>><br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> Beginners mailing list<br>
>> <a href="mailto:Beginners@haskell.org">Beginners@haskell.org</a><br>
>> <a href="http://www.haskell.org/mailman/listinfo/beginners" target="_blank">http://www.haskell.org/mailman/listinfo/beginners</a><br>
>><br>
><br>
> _______________________________________________<br>
> Beginners mailing list<br>
> <a href="mailto:Beginners@haskell.org">Beginners@haskell.org</a><br>
> <a href="http://www.haskell.org/mailman/listinfo/beginners" target="_blank">http://www.haskell.org/mailman/listinfo/beginners</a><br>
><br>
<br>
_______________________________________________<br>
Beginners mailing list<br>
<a href="mailto:Beginners@haskell.org">Beginners@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/beginners" target="_blank">http://www.haskell.org/mailman/listinfo/beginners</a><br>
</div></div></blockquote></div><br></div>