0
Prelude> [0.1,0.2..1.0]
[0.1,0.2,0.30000000000000004,0.4000000000000001,0.5000000000000001,0.6000000000000001,0.7000000000000001,0.8,0.9,1.0]

Why only 0.8 and 0.9 are correct?

In other cases like [0.1,0.11..0.2] you also get a few initial values correct, but many others are wrong.

I wonder what the problem is here.

user61801
  • 9
  • 1
  • 5
    https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html. Simplified tl;dr: floating-point arithmetic is _always wrong_ by a small epsilon (which doesn't matter in the intended application – physical quantities – because these can only ever be measured with some uncertainty anyway. — If you need exact results use an exact type. E.g. `[0.1, 0.2 .. 1] :: [Rational]` gives `[1 % 10,1 % 5,3 % 10,2 % 5,1 % 2,3 % 5,7 % 10,4 % 5,9 % 10,1 % 1]`, to be read as `[1/10, 1/5, 3/10 ...]`. – leftaroundabout Jul 11 '17 at 10:50
  • perfect, thanks! I got tricked by the fact that, as a human, for me it's clear that the step in that case is 0.1, but I suppose GHC does not care and whether the step is small or not it follows always the same steps which introduce the error. – user61801 Jul 11 '17 at 11:04
  • Well, that's not really the issue; just, the number `0.1 ≡ ¹⁄₁₀` doesn't really exist in (binary-) floating-point arithmetic. It only has a close approximation, namely `7205759403792794 · 2⁻⁵⁶`. And `7205759403792794 * 10` is almost, but not quite the same as `2⁵⁶ = 72057594037927936`. If you directly compute `0.1 * 10` you don't notice that because it happens to be rounded to the correct value, but `0.1 * 3` is rounded to `0.30000000000000004` instead. – leftaroundabout Jul 11 '17 at 11:17

0 Answers0