Re: RE:Working Precision
- To: mathgroup at smc.vnet.net
- Subject: [mg24090] Re: [mg23928] RE:Working Precision
- From: "Allan Hayes" <hay at haystack.demon.co.uk>
- Date: Fri, 23 Jun 2000 02:26:58 -0400 (EDT)
- References: <8ihv28$led@smc.vnet.net> <8in7e4$4kc@smc.vnet.net> <8is6im$gtb@smc.vnet.net>
- Sender: owner-wri-mathgroup at wolfram.com
I wonder if Richard Fateman wrote this tongue in cheek, witness "When you must store the result into a finite sized memory". Replacing inexact reals by rationals before computing often results in running out of memory. And, of course, there is the question of which fractions to use initially -any variation here has consequences for the answer. -- Allan --------------------- Allan Hayes Mathematica Training and Consulting Leicester UK www.haystack.demon.co.uk hay at haystack.demon.co.uk Voice: +44 (0)116 271 4198 Fax: +44 (0)870 164 0565 "Philip C Mendelsohn" <mend0070 at garnet.tc.umn.edu> wrote in message news:8is6im$gtb at smc.vnet.net... > Richard Fateman (fateman at cs.berkeley.edu) wrote: > > : Here's an easily defended rule: Do all arithmetic exactly. When > : you must store the result into a finite sized memory location, > : round it to the nearest representable number exactly representable > : in that memory location. In case of a tie, round to even. > > Numeric math is not my expertise, but is your error not limited by > the intervals between exactly representable numbers? And, if performing > calculations on numbers that have been stored, is not the propagation > (and acculmulation) of error still present? > > Pardon my ignorance, but I fail to see how this rule improves anything. > The best thing would be to do exact arithmetic all along, and only convert > to the required precision at the very end, but I doubt it would be > the fastest or most economical approach. > >