I saw [this comment](https://news.ycombinator.com/item?id=41112688) on Hacker News the other day:
> > The number of floats between 0 and 1 is the same as the number of floats between 1 and 3
>
> No, the number of floats between 0 and 1 is (approximately) the same as the number of floats between 1 and _positive infinity_. And this is the correct way for it work: 1/x has roughly the same range and precision as x, so you don't need (as many) stupid obfuscatory algebraic transforms in your formulas to keep your intermediate values from over- or under-flowing.
Some people disagreed with him in the replies, so I decided to check for myself:
```rust
fn main() {
let mut count_between_0_and_1 = 0u32;
let mut count_between_1_and_inf = 0u32;
for bits in 0..=u32::MAX {
let f = f32::from_bits(bits);
if f.is_finite() {
if 0.0 < f && f < 1.0 {
count_between_0_and_1 += 1;
} else if 1.0 <= f {
count_between_1_and_inf += 1;
}
}
}
let ratio = count_between_0_and_1 as f64 / count_between_1_and_inf as f64;
println!("Count between 0 and 1: {}", count_between_0_and_1);
println!("Count between 1 and +inf: {}", count_between_1_and_inf);
println!("Ratio: {:.1}", ratio);
}
```
And I think the commenter was right:
```
Count between 0 and 1: 1065353215
Count between 1 and +inf: 1073741824
Ratio: 1.0
```
We are further enlightened by [another comment](https://news.ycombinator.com/item?id=13769959) in another thread that I found:
> The correct answer is 1,065,353,216.
> This is easy to work out yourself if you remember one basic, handy property of floats: adjacent floats are adjacent in bit representation, except -0.0f and 0.0f.
>
> For example, 0x00000000 is +0.0f. 0x00000001 is the smallest non-zero positive float. 0x00000002 is the second smallest.
>
> The only exception to this is -0.0f and +0.0f, which are 0x80000000 and 0x00000000. The rule works with denormal floats, normal floats, and even right on the line between the two. If you want the next positive float, you always just add 0x00000001.
>
> Now, +1.0f happens to be 0x3f800000. Recall +0.0f is 0x00000000. The number of values between the two is 0x3f800000 - 0x00000000 == 0x3f800000. Write that in decimal and you get 1065353216.
They got `1065353216` while I got `1065353215` because they counted 0 and I did not. We both did not include 1.
By the way, [the article](https://lemire.me/blog/2017/02/28/how-many-floating-point-numbers-are-in-the-interval-01/) the second commenter was commenting under is quite good and I recommend it. I will note that the author says there are `1,056,964,610` "normal floating-point numbers" in \[0,1) and I am not entirely sure why this disagrees with the number I produced.