From: nmm1 on 1 Aug 2010 14:12 In article <1jmjjde.14qbtbo1ptpprwN%nospam(a)see.signature>, Richard Maine <nospam(a)see.signature> wrote: > >Many people (myself included) do deprecate floating point equality tests >for the reason that Philip mentioned. Depending on exact results from >any floating point operation is risky except in special cases where you >can be sure that no rounding would have been involved on any practical >system. Rounding is fundamental to floating point. I recommend against >using floating point at all until you have at least a basic appreciation >of the implications of rounding. Yes, that means I think one needs to >get a basic appreciation of the implications of rounding very early in >learning Fortran. It doesn't need to be very sophisticated - just >knowing that anything involving floating point can be inexact is >sufficient for a start. While that is all true, many other people (myself included) do NOT deprecate floating-point equality tests, any more than relying on ordering tests giving the 'right' order. I completely agree about the need to understand rounding, and teach the viewpoint that floating-point (whether by hand or on a computer) is an INEXACT arithmetic. Yes, I am old-fashioned, there :-) Unfortunately, IEEE 754 has made this area significantly trickier, by introducing denormalised numbers, which have different semantics in the area of comparisons. Note that I am NOT saying that they are worse than hard underflow - just that they are different - so programmers now need to understand both models. Regards, Nick Maclaren.
From: Dr Ivan D. Reid on 1 Aug 2010 14:14 On Sun, 1 Aug 2010 10:25:33 -0700 (PDT), analyst41(a)hotmail.com <analyst41(a)hotmail.com> wrote in <0c4876d4-d487-40d0-9d26-0721e809a35a(a)w15g2000pro.googlegroups.com>: > OK - so tests for Floating point ">",">=","<" and "<=" are subject to > the same processor-dependencies as a direct or indirect test for "=="? In a word, yes. While there are cases where floating-point can return exact representations of a number (e.g. integers within a finite range) the vast majority of numbers are not exactly representable and the floating-point _approximation_ you arrive at for those numbers may well differ depending on the computation chain used to arrive at the number. -- Ivan Reid, School of Engineering & Design, _____________ CMS Collaboration, Brunel University. Ivan.Reid@[brunel.ac.uk|cern.ch] Room 40-1-B12, CERN KotPT -- "for stupidity above and beyond the call of duty".
From: dpb on 1 Aug 2010 14:28 analyst41(a)hotmail.com wrote: .... > OK - so tests for Floating point ">",">=","<" and "<=" are subject to > the same processor-dependencies as a direct or indirect test for "=="? I'd amplify the other remark by the non-technical statement of "of course". Consider that the branch to be taken is dependent in the end on the comparison of whether either fp quantity A or fp quantity B is, or is not, different in a particular direction from the other in that last bit of precision. Fundamentally, that's no different than whether they're equal to the last bit or not as to whether the comparison falls one side or the t'other. --
From: Carlie Coats on 2 Aug 2010 08:52 Dr Ivan D. Reid wrote: > On Sun, 1 Aug 2010 10:25:33 -0700 (PDT), analyst41(a)hotmail.com > <analyst41(a)hotmail.com> > wrote in<0c4876d4-d487-40d0-9d26-0721e809a35a(a)w15g2000pro.googlegroups.com>: > >> OK - so tests for Floating point ">",">=","<" and"<=" are subject to >> the same processor-dependencies as a direct or indirect test for "=="? > > In a word, yes. While there are cases where floating-point can > return exact representations of a number (e.g., [small integers]... ISTR that on some early vector machines, even these small integers would fail (something like "x=10.0; print *,x" would return maybe 9.9999999999999999). And comparisons for exact-10 might well fail. ;-( -- Carlie Coats
First
|
Prev
|
Pages: 1 2 Prev: solutions manual Next: Discount Wholesale Coogi Jeans <free shipping paypal payment> |