From: Przemek K. <prz...@ni...> - 2016-02-04 22:03:19
|
> Przemek wrote: > > But it's the users' self-inflicted wound, because they chose to use > floats. Dramatic increase of the number of significant digits in > simple calculations is just the way the floats work: 1/3 is 1/3, but > 1.0/3.0 is 0.333333333333333333333..... Of course > solve(log(2)*x^2+log(3)*x+log(5),x) does not have this problem and > returns a pretty, compact result. > On 02/04/2016 12:24 PM, Soegtrop, Michael wrote: > This happens frequently to me with physical problems, where I have > some decimal numbers from tables. I keep all values symbolic as long > as possible, but in some cases it is substantially harder to solve an > equation with all values being symbolic than with numerical values. > Also in some cases one wants certain numeric values to be combined to > judge their size. I could write 357/1000 for 0.357, but this is not > very comfortable and wouldn’t solve the problem of resulting in huge > integers either. > > So here's this crazy thing that always bothered me: in most engineering problems, the input data is accurate to few percent, i.e. has two or three significant digits, well described by a 16-bit, 3-significant-digit-mantissa half-precision floating point format numbers. The main reason we use 32-bit 6-digit single precision or 64-bit 15-digit double precision numbers is that we have fallen into complacency, relying on the excess precision preserving enough accuracy from the input to the result. As most people on this list know, this often pans out but mostly by dumb luck and black magic: many common algorithms' error propagation properties are poorly known and weakly understood. Recently someone here published a beautiful example of a simple polynomial that calculates consistent but incorrect results in both single and double precision, which is a great trick to show to those who consider cross-checking of single and double precision results to be the ultimate sophistication in error analysis. I really believe that if you care about accuracy you really need to either calculate the error propagation, or use interval arithmetic. If you don't care, you might as well live with 1/3=0.33333 |