Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!cs.utexas.edu!oakhill!steve
From: steve@oakhill.UUCP (steve)
Newsgroups: comp.lang.c
Subject: Re: x/10.0 vs x*0.1
Summary: The true story
Message-ID: <1573@devsys.oakhill.UUCP>
Date: 14 Oct 88 21:59:52 GMT
References: <836@proxftl.UUCP> <3105@hubcap.UUCP> <1700@dataio.Data-IO.COM> <2888@edsews.EDS.COM>
Organization: Motorola Inc. Austin, Tx
Lines: 41

In article <2888@edsews.EDS.COM>, charette@edsews.EDS.COM (Mark A. Charette) writes:
> In article <13969@mimsy.UUCP>, chris@mimsy.UUCP (Chris Torek) writes:
> > 
> > Yes (subject to the usual constraints, i.e., that you know what you are
> > doing: if your input data has little precision, you can afford minor
> > degredations in computations).
> 
> Some numerical analysts I associate with might argue that the propagation
> of any error in floating point tends to be magnified as more operations
> occur. I have had occasion to see the (small) precision in some data be
> completely outweighed by using float instead of double (actually REAL
> instead of DOUBLE PRECISION, but this is comp.lang.c ;') and really
> whacking at the data (conversions back and forth between double and float).
>  
I have seen an actual case of this 'minor' error blow out of proportion.
The case was reading the digits after a decimal point for a fortran
compiler.  The code look something like this (psuedo-code).

end = 0.0;
back = 0.1;
thischar = first character after decimal;
while (isdigit(thischar))
  {
  end = end + (thischar - '0') * back;
  back = back * 0.1;
  thischar = next character;
  }

On numbers with large decimal parts, the error added up quickly enough to
cause errors by the end of the read.  This error started an cascade of
rewrites that totally changed the algorithm used - but thats another story.

                   enough from this mooncalf - Steven
----------------------------------------------------------------------------
These opinions aren't necessarily Motorola's or Remora's - but I'd like to
think we share some common views.
----------------------------------------------------------------------------
Steven R Weintraub                        cs.utexas.edu!oakhill!devsys!steve
Motorola Inc.  Austin, Texas 
(512) 440-3023 (office) (512) 453-6953 (home)
----------------------------------------------------------------------------