F# Floating point ranges are experimental and may be deprecated

Question

I\'m trying to make a little function to interpolate between two values with a given increment.

[ 1.0 .. 0.5 .. 20.0 ]

The compiler tells m

Answer 1

TL;DR: F# PowerPack's BigRational type is the way to go.

---

What's Wrong with Floating-point Loops

As many have pointed out, float values are not suitable for looping:

• They do have Round Off Error, just like with 1/3 in decimal, we inevitably lose all digits starting at a certain exponent;
• They do experience Catastrophic Cancellation (when subtracting two almost equal numbers, the result is rounded to zero);
• They always have non-zero Machine epsilon, so the error is increased with every math operation (unless we are adding different numbers many times so that errors mutually cancel out -- but this is not the case for the loops);
• They do have different accuracy across the range: the number of unique values in a range [0.0000001 .. 0.0000002] is equivalent to the number of unique values in [1000000 .. 2000000];

Solution

What can instantly solve the above problems, is switching back to integer logic.

With F# PowerPack, you may use BigRational type:

open Microsoft.FSharp.Math
// [1 .. 1/3 .. 20]
[1N .. 1N/3N .. 20N]
|> List.map float
|> List.iter (printf "%f; ")

Note, I took my liberty to set the step to 1/3 because 0.5 from your question actually has an exact binary representation 0.1_b and is represented as +1.00000000000000000000000 * 2^-1; hence it does not produce any cumulative summation error.

Outputs:

1.000000; 1.333333; 1.666667; 2.000000; 2.333333; 2.666667; 3.000000; (skipped) 18.000000; 18.333333; 18.666667; 19.000000; 19.333333; 19.666667; 20.000000;

// [0.2 .. 0.1 .. 3]
[1N/5N .. 1N/10N .. 3N]
|> List.map float
|> List.iter (printf "%f; ")

Outputs:

0.200000; 0.300000; 0.400000; 0.500000; (skipped) 2.800000; 2.900000; 3.000000;

Conclusion

• BigRational uses integer computations, which are not slower than for floating-points;
• The round-off occurs only once for each value (upon conversion to a float, but not within the loop);
• BigRational acts as if the machine epsilon were zero;

There is an obvious limitation: you can't use irrational numbers like pi or sqrt(2) as they have no exact representation as a fraction. It does not seem to be a very big problem because usually, we are not looping over both rational and irrational numbers, e.g. [1 .. pi/2 .. 42]. If we do (like for geometry computations), there's usually a way to reduce the irrational part, e.g. switching from radians to degrees.

---

Further reading:

• What Every Computer Scientist Should Know About Floating-Point Arithmetic
• Numeric types in PowerPack

Answer 2

Interestingly, float ranges don't appear to be deprecated anymore. And I remember seeing a question recently (sorry, couldn't track it down) talking about the inherent issues which manifest with float ranges, e.g.

> let xl = [0.2 .. 0.1 .. 3.0];;

val xl : float list =
  [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; 2.1; 2.2; 2.3; 2.4; 2.5; 2.6; 2.7; 2.8; 2.9]

I just wanted to point out that you can use ranges on decimal types with a lot less of these kind of rounding issues, e.g.

> [0.2m .. 0.1m .. 3.0m];;
val it : decimal list =
  [0.2M; 0.3M; 0.4M; 0.5M; 0.6M; 0.7M; 0.8M; 0.9M; 1.0M; 1.1M; 1.2M; 1.3M;
   1.4M; 1.5M; 1.6M; 1.7M; 1.8M; 1.9M; 2.0M; 2.1M; 2.2M; 2.3M; 2.4M; 2.5M;
   2.6M; 2.7M; 2.8M; 2.9M; 3.0M]

And if you really do need floats in the end, then you can do something like

> {0.2m .. 0.1m .. 3.0m} |> Seq.map float |> Seq.toList;;
val it : float list =
  [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; 2.1; 2.2; 2.3; 2.4; 2.5; 2.6; 2.7; 2.8; 2.9; 3.0]

Answer 3

As Jon and others pointed out, floating point range expressions are not numerically robust. For example [0.0 .. 0.1 .. 0.3] equals [0.0 .. 0.1 .. 0.2]. Using Decimal or Int Types in the range expression is probably better.

For floats I use this function, it first increases the total range 3 times by the smallest float step. I am not sure if this algorithm is very robust now. But it is good enough for me to insure that the stop value is included in the Seq:

let floatrange start step stop =
    if step = 0.0 then  failwith "stepsize cannot be zero"
    let range = stop - start 
                |> BitConverter.DoubleToInt64Bits 
                |> (+) 3L 
                |> BitConverter.Int64BitsToDouble
    let steps = range/step
    if steps < 0.0 then failwith "stop value cannot be reached"
    let rec frange (start, i, steps) =
        seq { if i <= steps then 
                yield start + i*step
                yield! frange (start, (i + 1.0), steps) }
    frange (start, 0.0, steps)

Answer 4

Updated version of Tomas Petricek's answer, which compiles, and works for decreasing ranges (and works with units of measure): (but it doesn't look as pretty)

let rec frange(from:float<'a>, by:float<'a>, tof:float<'a>) = 
   // (extra ' here for formatting)
   seq { 
        yield from
        if (float by > 0.) then
            if (from + by <= tof) then yield! frange(from + by, by, tof) 
        else   
            if (from + by >= tof) then yield! frange(from + by, by, tof) 
       }

#r "FSharp.Powerpack"
open Math.SI 
frange(1.0<m>, -0.5<m>, -2.1<m>)

UPDATE I don't know if this is new, or if it was always possible, but I just discovered (here), that this - simpler - syntax is also possible:

let dl = 9.5 / 11.
let min = 21.5 + dl
let max = 40.5 - dl

let a = [ for z in min .. dl .. max -> z ]
let b = a.Length

(Watch out, there's a gotcha in this particular example :)

Answer 5

Try the following sequence expression

seq { 2 .. 40 } |> Seq.map (fun x -> (float x) / 2.0)

Answer 6

You can also write a relatively simple function to generate the range:

let rec frange(from:float, by:float, tof:float) =
   seq { if (from < tof) then 
            yield from
            yield! frange(from + by, tof) }

Using this you can just write:

frange(1.0, 0.5, 20.0)