[Date Index] [Thread Index] [Author Index]

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.
>
>