Re: Off by 0.00000001, Why?
- To: mathgroup at smc.vnet.net
- Subject: [mg37390] Re: [mg37378] Off by 0.00000001, Why?
- From: "Steven T. Hatton" <hattons at globalsymmetry.com>
- Date: Sat, 26 Oct 2002 02:03:22 -0400 (EDT)
- Organization: Global Symmetry
- References: <768AB868-E81E-11D6-86DE-0003938BF55C@jeol.com>
- Sender: owner-wri-mathgroup at wolfram.com
On Friday 25 October 2002 09:34 am, you wrote: > This is not surprising. First of all as you correctly pointed out the > Mathematica routines you are calling may have changed and therefore > produce different results. This is not a high priority for me, but it would be nice to know how to identify the source of such discrepancies. > Secondly your OS and hardware platform may > not be identical and in my experience the same compiler may produce > different results on different hardware and OS combinations due to > different optimizations applied to floating point expressions. > Finally, Intel chips have floating point registers that are actually 80 > bits wide. Thus they perform some floating point operations > differently than a pure 64 bit machine because they may use 80 bits for > intermediate results. See > http://www.validlab.com/goldberg/addendum.html for a reasonable summary > of the issues with floating point computations on different > architectures. I *believe* Java trys to create a platform neutral computing environment which insures results will be uniform across platforms. IIRC, I read something about this kind of thing in the Mathematica documentation. There are ways of manipulating the content of atoms which can be used to optimize performance, but they are discouraged because they can lead to the kinds of discrepancies were are discussing.... Indeed, see A.1.4 of the Mathematica Book: (4.2, Help Browser) "As an optimization for some special kinds of computations, the raw data in Mathematica atomic objects can be given explicitly using Raw[head, "hexstring"]. The data is specified as a string of hexadecimal digits, corresponding to an array of bytes. When no special output form exists, InputForm prints special objects using Raw. The behavior of Raw differs from one implementation of Mathematica to another; its general use is strongly discouraged. " > > Any thoughts on this? > > If your floating point calculations are mission critical you have to > use a compiler which allows you to control whether floating point > expressions are optimized. Also you have to use a CPU architecture > whose behavior you understand. Finally all of your algorithms must be > analyzed to guarantee you understand and have compensated for the > floating point model of your compiler and CPU. This is why mission > critical code such as for NASA is typically audited by a team before > being committed to production code. I do seem to recall a lost probe not too long ago. Seems someone forgot to convert from miles to kilometers, or something like that. To my mind that was just plain stupidity. They should never have been using imperial units in the first place. Nonetheless, this demonstrates the kinds of things which can creep into your calculations. Suppose the Auditors come in and bless everything off, and the next week you get a brand new computer. Not realizing that the hardware will influence the outcome of your calculation, you copy everything over to the new system, give the nice lady at WRI a call to get your new password, and run the calculations 10 times faster, but based on assumptions which are inconsistent with your current environment. Ooops, "Houston, we've got a problem." > Regards, > > Ssezi -- STH Hatton's Law: "There is only One inviolable Law."
- Follow-Ups:
- Re: Re: Off by 0.00000001, Why?
- From: jmt <jmt@dxdydz.net>
- Re: Re: Off by 0.00000001, Why?