Re: floor problems

*To*: mathgroup at smc.vnet.net*Subject*: [mg8166] Re: [mg8113] floor problems*From*: David Withoff <withoff>*Date*: Sat, 16 Aug 1997 11:51:10 -0400*Sender*: owner-wri-mathgroup at wolfram.com

> Hello Mathematica users. > > I had a very frustrating time trying to debug some work I was doing in > Mathematica. I finally pared it down to a problem with the Floor > function, and I have illustrated my concern below. I am using M 3.0 and > a Mac computer. Does anyone have any advice or could you tell me if I > am doing something wrong? > > Floor[(.7 67 10)] > > 469 > > Floor[(67 10 .7)] > >468 > > Sincerely, > > Tom De Vries > -- > Vermilion Home Education Program > > email: tom.devries at schoolofhope.org >email: toad at planet.eon.net I think that there are two distinct questions here: 1) Why is Floor[(.7 67 10)] different than Floor[(67 10 .7)] 2) Since the exact result from 7/10 67 10 is 469, why does Floor[(67 10 .7)] return 468? The answer to the first question is that this is a consequence of the limitations of machine arithmetic. The same "bug" is present in nearly all computer software. As distressing as this may seem, the fact is that multiplication of machine numbers is not commutative. Here, for example, is a simple C program: -------------------------------------------------------------- #include <math.h> main() { double x, y; x = floor(0.7 * 67 * 10); y = floor(67 * 10 * 0.7); printf ("floor(0.7 * 67 * 10) = %f\n", x); printf ("floor(67 * 10 * 0.7) = %f\n", y); } --------------------------------------------------------------- which on my computer gives a result which is equivalent to the result from Mathematica. floor(0.7 * 67 * 10) = 469.000000 floor(67 * 10 * 0.7) = 468.000000 Lots of people have devoted decades of their lives to stabilizing numerical algorithms against the effects of this and other idiosyncracies of machine arithmetic. The answer to the second question, again both in Mathematica and in other systems, is that this is a design decision. An inexact number (a number in which the last digits are uncertain) is usually best thought of as an interval rather than as a point. For example, a number like 2.00000 can be thought of as the best available six-digit representation for any number between 1.9999995 and 2.000005. Since this interval includes 2, there is an obvious question about whether the "floor" of that number should be 2 or 1. There are lots of ways to handle this ambiguity which have different advantages in different situations, but eventually it comes down to a design decision. In Mathematica, one of the primary reasons for including variable-precision arithmetic is to provide a way to get around the idiosyncracies of machine arithmetic. Variable-precision is not without idiosyncracies either, but it is far more reliable and consistent than machine arithmetic. With variable precision arithmetic, rather than machine arithmetic, you should be able to get consistent results from these calculations. The best solution, however, for this and almost any other similar problem in numerical analysis, whether you write this program in C or in Fortran or in Mathematica or in any other system, is to arrange your calculation so that it is not sensitive to how the system chooses to handle these ambiguities. Dave Withoff Wolfram Research

**Re: floor problems**

**Re: UnsameQ implementation**

**Re: floor problems**

**Re: floor problems**