As a lumpy-bumpy rule (working knowledge): Keep away 2 orders of magnitude from the $MachineEpsilon:

In[58]:= 1. < 1. + 2.22045 10^(-14)
Out[58]= True

In[59]:= 1. < 1. + 1. 10^(-14)
Out[59]= False

In[56]:= 1. < 1. + 2.22507*10.^(-15)
Out[56]= False

In[57]:= $MachineEpsilon
Out[57]= 2.22045*10^-16

and zero always works:

In[60]:= 0. < 2.22507*10.^(-308)
Out[60]= True

In[61]:= 0. < 2.22507*10.^(-3080)
Out[61]= True

and do not compare numerical relationships around 0. with numerical relationships around 1.

To expand, Mathematica's approximate numbers do not represent a "floating point model" in the sense that IEEE 754 numbers do. IEEE 754 is explicitly a specification for arithmetic using a defined subset of rational numbers. That's fine as the specification of a floating point hardware unit, but it's not really a model of physical quantities.

Consider that my outside thermometer reads 31.4 at this moment. It looks like a rational number but the physical reality isn't really any sort of mathematical number. The number is just a convenient connection from the air to the mathematics. Another thermometer in the same place would probably yield a slightly different number. When you ask for temperature at high precision, things get fuzzy: real physical systems are never exactly in thermal equilibrium and even defining exactly what the system is can get very tricky. In statistical mechanics, the temperature of a finite physical system necessarily fluctuates. No two thermometers are identical. This is the normal state of affairs for physical quantities in general.

Most programming systems simply gloss over this distinction. You get get a floating point implementation that's rigorous in its behavior from the point of view of a floating point implementor, but how it models reality is up to you. Mathematica, the invention of a physicist, goes a step or two farther toward modeling the way physical quantities work. It has a fast implementation layered atop your machine's native floating point, and a more rigorous implementation for greater precision and better tracking of precision.

You should not think of approximate numbers in Mathematica as floating point, although in some cases floating point is involved in their implementation. Approximate numbers are approximate numbers. But, if you want rigorous calculations over a subset of rationals, Mathematica gives you a much larger subset and greater mathematical rigor than IEEE 754 does.

For real physical rigor, you should explicitly maintain a probability distribution for every quantity and do arithmetic via Bayes' theorem. I have colleagues who have done that (not in Mathematica) for tricky physical calculations. Of course, in practice you can only do this approximately, and it scales horribly. It's not suitable as a model for quantities in a general-purpose system. Mathematica's approach is a good compromise.

Consider to read this Why is (-1.)^2. a Complex Number? related discussion.

There are many conventions Mathematica flouts. There would be no point to Mathematica if it was the same as FORTRAN. There are conventions for many kinds of tools, but a chainsaw doesn't follow the conventions for handsaw construction. And, of course, if you expect a chainsaw to behave like a handsaw you're likely to injure yourself.

It does not even guarantee that machine numbers will be encoded according to IEEE 754

Maple states in How Maple Compares to Mathematica p 15 Numerics, that Mathematica does not follow IEEE 754.

There is no law of nature that makes IEEE 754 the true path.

Standards are about convention, not about truth.

Usually about 2 orders of magnitude above the $MachineEpsilon Mathematica does things right

In[1]:= Table[{o, Floor[1. - 10^o $MachineEpsilon]}, {o, 0, 5}] 
Out[1]= {{0, 0}, {1, 0}, {2, 0}, {3, 0}, {4, 0}, {5, 0}}

In[3]:= Table[{o, 1. - 10^o $MachineEpsilon < 1.}, {o, 0, 5}]
Out[3]= {{0, False}, {1, False}, {2, True}, {3, True}, {4, True}, {5, True}}

 In[4]:= 10^(-14) < 100 $MachineEpsilon
 Out[4]= True

Results in the area of $MachineEpsilon are not results.

It is clear that both numbers, 0.7and 0.7000000000000001 are MachinePrecision numbers. Nevertheless they are different and the latter is larger than the former and so Table is not obeying the upper limit which I provided to it!

Range is doing it correctly -- as also your example with using higher precision numbers shows: all elements in the resulting list are between the lower and upper bound, i.e., <0.7

Your example of 0.7000000000000001 == 7/10 shows another severe problem with Mathematica. Here 7/10 is first converted (correctly) to a MachinPrecision Number (because the left side is also only of MachinePrecision), which results in

In[73]:= N[7/10]//FullForm
Out[73]//FullForm= 0.7`

Then they are compared

In[100]:= 0.7000000000000001`==0.7`
Out[100]= True

This is a strange result as the two numbers are obviously different. I know, that the documentation says that Equal etc. are dropping the last 8 digits when comparing. But I do not understand why it is dropping precision (no other language I know does this!) which leads to strange and inconsistent results like in

In[96]:= Floor[1.- 10^-14]
Out[96]= 0
In[95]:= 1.-( 10^-14) < 1.
Out[95]= False

The first result says that 1.- 10^-14 is definitely smaller than 1. and the second says that it is not!

Hi Berthold,

I can see your point, but if the two numbers 0.7and 0.7000000000000001 were compared in a way you are expecting it, then it would be a matter of pure chance whether the last entry in your list (the result of Table[x, {x, 0.1, 0.7, 0.1}]) is 6.9... or 7.0...

What is needed is some meaningful comparison of two floating point numbers. From a pure numerical point of view such a comparison does not make any sense - unless you take some measures: The Documentation e.g. for Equal (==) says

Approximate numbers with machine precision or higher are considered equal if they differ in at most their last seven binary digits (roughly their last two decimal digits).

This is to be kept in mind.

Henrik

You asked for approximate numbers. 0.7000000000000001 is approximately 7/10:

In[72]:= 0.7000000000000001 == 7/10

Out[72]= True

Mathematica makes no guarantee that approximate numbers computed in different ways will be identical even if they compare as equal and would be mathematically identical if computed exactly. If you want exact numbers, specify exact numbers as input:

In[78]:= Table[n, {n, 1/10, 7/10, 1/10}]

Out[78]= {1/10, 1/5, 3/10, 2/5, 1/2, 3/5, 7/10}

Note that your apparently exact results are generally not exact: fractions whose denominators are not powers of two cannot be exactly represented in floating point binary. 0.7 only appears to be exact when rounded to the nearest decimal in machine precision . But it's a little off. You can see this if you ask for additional precision:

In[79]:= SetPrecision[Range[0.1, .7, .1], 25]

Out[79]= {0.1000000000000000055511151, 0.2000000000000000111022302, \
0.3000000000000000444089210, 0.4000000000000000222044605, \
0.5000000000000000000000000, 0.5999999999999999777955395, \
0.6999999999999999555910790}

Hi Berthold,

you are asking for floating point numbers, and these come with machine precision ...

Henrik