From: analyst41 on 1 Aug 2010 11:54 when one can easily write if (A > B) THEN stuff ELSEIF ( A < B) THEN stuff ELSE stuff for the "equal" case ENDIF
From: Phillip Helbig---undress to reply on 1 Aug 2010 12:03 In article <df5a3155-6e31-435d-9776-ed22b47d6122(a)f20g2000pro.googlegroups.com>, "analyst41(a)hotmail.com" <analyst41(a)hotmail.com> writes: > when one can easily write > > if (A > B) THEN > > stuff > > ELSEIF ( A < B) THEN > > stuff > > ELSE > > stuff for the "equal" case > > ENDIF Because the results are processor-dependent, since different rounding schemes will produce different results.
From: Ron Shepard on 1 Aug 2010 12:23 In article <df5a3155-6e31-435d-9776-ed22b47d6122(a)f20g2000pro.googlegroups.com>, "analyst41(a)hotmail.com" <analyst41(a)hotmail.com> wrote: > if (A > B) THEN > > stuff > > ELSEIF ( A < B) THEN > > stuff > > ELSE > > stuff for the "equal" case > > ENDIF I'm not exactly sure what is the question, but I think with IEEE floating point and the appropriate values for A and B, all four of the following branches can be executed. if (A > B) THEN stuff ELSEIF ( A < B) THEN stuff ELSEIF ( A == B ) THEN stuff for the "equal" case ELSE stuff involving Inf and NaN ENDIF However, the mapping between the IEEE values and the fortran tests may be processor dependent or dependent on compiler options (e.g. tests for equality between the two zero values). Also, the order of the first three tests may affect which branch is taken in some cases. The tests can also be done with functions from the IEEE module, which eliminates the processor dependence among IEEE machines but makes the code less portable. $.02 -Ron Shepard
From: analyst41 on 1 Aug 2010 13:25 On Aug 1, 12:23 pm, Ron Shepard <ron-shep...(a)NOSPAM.comcast.net> wrote: > In article > <df5a3155-6e31-435d-9776-ed22b47d6...(a)f20g2000pro.googlegroups.com>, > > "analys...(a)hotmail.com" <analys...(a)hotmail.com> wrote: > > if (A > B) THEN > > > stuff > > > ELSEIF ( A < B) THEN > > > stuff > > > ELSE > > > stuff for the "equal" case > > > ENDIF > > I'm not exactly sure what is the question, but I think with IEEE > floating point and the appropriate values for A and B, all four of > the following branches can be executed. > > if (A > B) THEN > stuff > ELSEIF ( A < B) THEN > stuff > ELSEIF ( A == B ) THEN > stuff for the "equal" case > ELSE > stuff involving Inf and NaN > ENDIF > > However, the mapping between the IEEE values and the fortran tests > may be processor dependent or dependent on compiler options (e.g. > tests for equality between the two zero values). Also, the order of > the first three tests may affect which branch is taken in some > cases. The tests can also be done with functions from the IEEE > module, which eliminates the processor dependence among IEEE > machines but makes the code less portable. > > $.02 -Ron Shepard OK - so tests for Floating point ">",">=","<" and "<=" are subject to the same processor-dependencies as a direct or indirect test for "=="?
From: Richard Maine on 1 Aug 2010 13:48 Phillip Helbig---undress to reply <helbig(a)astro.multiCLOTHESvax.de> wrote: > In article > <df5a3155-6e31-435d-9776-ed22b47d6122(a)f20g2000pro.googlegroups.com>, > "analyst41(a)hotmail.com" <analyst41(a)hotmail.com> writes: [most of his question in the subject line] > > > when one can easily write > > if (A > B) THEN .... > > ELSEIF ( A < B) THEN .... > > ELSE > > > > stuff for the "equal" case > > > > ENDIF > > Because the results are processor-dependent, since different rounding > schemes will produce different results. And because of that, the alternate form shown above is just as deprecated as any other form. At least I deprecate it just as much. It is the dependence on exact equality that I deprecate - not some particular syntax. The above form depends on exact equality just as much as a test with "==" would. If you find someone who deprecates one form but not the other, then you should ask them why instead of asking the world at large. I would disagree with any such distinction. If you have found a compiler that deprecates one form but not the other, that is probbaly just because the one form is trivial to detect, while the other is not (particularly as one could further obfuscate the other without changing its essential nature). Note also that there is no such deprecation of floatting point equality tests in the standard. If you read somewhere that it is deprecated, I would hope that the author of the words you read would have clarified what he meant by that. If he just said that it "is deprecated", that would be sloppily imprecise writing in that it fails to specify who it is that does the deprecation. Using the passive voice often results in such sloppy writing (which is why I find it odd that some technical writing styles prefer it). In the context of a standardized programming language, the phrase "is deprecated" generally implies deprecation by some version of the standard unless there is specific qualification otherwise. That implication is false in this case (unless something like that slipped into f2008 when I wasn't looking.) 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. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
|
Next
|
Last
Pages: 1 2 Prev: solutions manual Next: Discount Wholesale Coogi Jeans <free shipping paypal payment> |