Hi Berthold,

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

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}

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

Mathematica has its own conventions for the behavior of approximate numbers. It follows them rigorously for its arbitrary precision numbers, and more heuristically for machine numbers. It does not even guarantee that machine numbers will be encoded according to IEEE 754, although most floating point hardware uses that standard these days.

There is no law of nature that makes IEEE 754 the true path. In my embedded work, using simple processors without hardware floating point, I sometimes wish IEEE 754 was not so ubiquitous: it is not an efficient standard for software floating point. Other languages generally use whatever the hardware and system libraries provide: in the past I've used much C on hardware with different floating point.

Mathematica is a very different language from the others you mentioned. Because it is different, it is often good at solving problems that the other languages you mention cannot easily solve. But, of course, that requires you to use its differences rather than fight them.

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.

Whatever floating point model Mathematica is using, the following should never happen:

It happens. Get over it. That you find this a problem indicates that you're fighting the tool, not using it. I've used Mathematica for a quarter of a century and I've never found its model of approximate arithmetic particularly troublesome. All such models have their particular problems. Don't confuse "familiar and conventional" with "correct and useful". Indeed, if you use explicit precision arithmetic or exact numbers, Mathematica has more capability than other systems here. Mathematica exists to solve problems, not to conform to your opinions.

You can also use the ComputerArithmetic package

In[21]:= Needs["ComputerArithmetic`"]

In[25]:= Ulp[0.]
Out[25]= 2.22507*10^-308

In[42]:= Ulp[ComputerNumber[0]]
Out[42]= If[\!\(\*
TagBox[
InterpretationBox["\<\"0.\"\>",
0.,
AutoDelete->True],
BaseForm[#, 10]& ]\) < 2.22507*10^-308, $MinMachineNumber, 
 ComputerArithmetic`Private`u$3699 = 
  N[2^Floor[
    Log[2, ComputerArithmetic`Private`t$3699 $MachineEpsilon] - 0.5]];
  ComputerArithmetic`Private`t$3699 = 
  ComputerArithmetic`Private`t$3699 - 
   ReleaseHold[
    ComputerArithmetic`Private`t$3699 - 
     ComputerArithmetic`Private`u$3699]; 
 If[ComputerArithmetic`Private`t$3699 == 0. || 
   ComputerArithmetic`Private`t$3699 == 
    2 ComputerArithmetic`Private`u$3699, 
  2 ComputerArithmetic`Private`u$3699, 
  ComputerArithmetic`Private`u$3699]]

In[43]:= Ulp[1. - 10.^(-14)]
Out[43]= 1.11022*10^-16

In[44]:= Ulp[-10.^(-14)]
Out[44]= 1.57772*10^-30

In[45]:= Ulp[1.]
Out[45]= 1.11022*10^-16

In[31]:= Arithmetic[]
Out[31]= {4, 10, RoundingRule -> RoundToEven, 
 ExponentRange -> {-50, 50}, MixedMode -> False, IdealDivide -> False,
  IdealDivision -> False}

In[37]:= ComputerNumber[1] - ComputerNumber[10^(-14)] < ComputerNumber[1]
Out[37]= False

In[38]:= ComputerNumber[1] - ComputerNumber[10^(-14)] -  ComputerNumber[1] < ComputerNumber[1] - ComputerNumber[1]
Out[38]= False

In[36]:= -ComputerNumber[10^(-14)] < ComputerNumber[0]
Out[36]= True

In[41]:= ComputerNumber[0] == ComputerNumber[1.] - ComputerNumber[1.]
Out[41]= True

Zero is a special number because its floating point representation is exact.

In[48]:= Ulp[-10.^(-14)]
Out[48]= 1.57772*10^-30

In[49]:= Ulp[1. - 10.^(-14)]
Out[49]= 1.11022*10^-16

In[50]:= Ulp[10^28 - 10.^(-14)]
Out[50]= 2.19902*10^12

the difference between two consecutive machine numbers raises with the numbers and from this numbers around 1. are not the same as 1. + (numbers around 0.) in numerics - in contrast to algebra.

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.