[sbanach]

Sure it does - in that any floating point scheme is a well defined partition of the real line in the range [-FLT_MAX, +FLT_MAX] into 2^n intervals (less two Infs, a load of NaNs and a spare zero), one of which absolutely contains 0.1

[sp332]

There are an infinite number of real values in the range [-FLT_MAX, +FLT_MAX], but only 2^n values can be represented with n bits. That means there are an infinite number of values in that range that cannot be represented with any number of bits.

[adaml_623]

Perhaps you could prove your point by supplying 0.1 in a binary floating point format. You can choose the standard.

[dbaupp]

The parent is referring to an interval, since floating point is essentially a disguised interval arithmetic.

For IEEE754 64-bit doubles, the interval containing 0.1 is: [0.099999999999999991673327315311, 0.100000000000000005551115123126]

[sbanach]

Sure adaml_623,

0x3dcccccd in IEEE 754-2008 (binary32) corresponds to the interval (0.09999999776482582, 0.10000000521540642) - which contains 0.1.

Disclaimers: I worked this out with double precision, and if you care about if the endpoints are inclusive/exclusive, the wikipedia article will help.

[Evbn]

X \elem S is not the same as X == S, in many important contexts.

[sbanach]

Agreed. I "proved my point" but I didn't do it "by supplying 0.1 in a binary floating point format", because that wasn't what my point was.

[Lexarius]

People often forget that IEEE 754 supports representations where b = 2 or 10. 1*10^-2 should be easy enough to store in any of the defined decimal layouts.