Re: Re: Off by 0.00000001, Why?
- To: mathgroup at smc.vnet.net
- Subject: [mg37411] Re: [mg37390] Re: [mg37378] Off by 0.00000001, Why?
- From: jmt <jmt at dxdydz.net>
- Date: Sun, 27 Oct 2002 06:33:04 -0500 (EST)
- References: <768AB868-E81E-11D6-86DE-0003938BF55C@jeol.com> <200210260603.CAA29496@smc.vnet.net>
- Reply-to: jmt at dxdydz.net
- Sender: owner-wri-mathgroup at wolfram.com
That's why you can use Mathematica arbitrary precision function to control your results. But you must know first what to control. On Saturday 26 October 2002 08:03, Steven T. Hatton wrote: > 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
- References:
- Re: Off by 0.00000001, Why?
- From: "Steven T. Hatton" <hattons@globalsymmetry.com>
- Re: Off by 0.00000001, Why?