From -8667948532701307200 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,9a5d91576ea14293 X-Google-Attributes: gid109fba,public X-Google-Thread: f78e5,42ca30940288d269 X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 1992-02-29 21:38:19 PST Xref: sparky comp.lang.c++:5426 comp.std.c++:253 Newsgroups: comp.lang.c++,comp.std.c++ Path: sparky!uunet!zaphod.mps.ohio-state.edu!uunet.ca!frumious!pat From: pat@frumious.uucp (Patrick Smith) Subject: Re: X to the Y power, how? Message-ID: <1992Mar1.041353.1323@frumious.uucp> Date: Sun, 1 Mar 1992 04:13:53 GMT Reply-To: uunet.ca!frumious!pat References: <22292@alice.att.com> <22305@alice.att.com> Organization: None In article <22305@alice.att.com> ark@alice.UUCP () writes: |Joe Buck's proposal for using @ for exponentiation goes quite far, but |omits one important detail: what is the value of x@y? | |That sounds like a trivial question -- it's just exponentiation, right? -- |but it is actually far from trivial. For example, if x@y is implemented |as exp(y*log(x)), the result will surely be inaccurate. So what, if |anything, should the user be entitled to assume? For example: I think this detail can safely be ignored. As far as I can tell, neither the ARM nor the ANSI C standard say anything (almost) about the exact values returned by other floating point operations. I just spent a few minutes searching the standard; I couldn't find anything about the result of multiplication more restrictive than The result of the binary * operator is the product of the operands. (X3.159 3.3.5, page 47; see also ARM 5.6, page 72). So why should exponentiation be more precisely defined? (There is one place where ANSI C specifies very accurate results: When a value of integral type is converted to floating type, if the value being converted is in the range of values that can be represented but cannot be represented exactly, the result is either the nearest higher or nearest lower value, chosen in an implementation-defined manner. in X3.159 3.2.1.3 on page 36; see also ARM 4.4, page 34. I find it curious that this one operation is so stringently restricted, while at the same time there's nothing preventing 2.0 * 3.0 == 17.0.) | Is x@2 guaranteed to be equal to x@2.0? To x*x? No. And x*3 is not guaranteed to be equal to x+x+x. If you do a floating point calculation two different ways, you can't expect to get the same answer both times. It's been a long time since I did any Fortran programming, but at the time this statement was also true in Fortran. (Have any of the Fortran standards changed this?) It may well be that people doing serious numerical programming won't want to use C++ unless the accuracy of floating point operations is more carefully specified. But if so, it needs to be done for all the floating point operations, not just exponentiation. |-- | --Andrew Koenig | ark@europa.att.com -- Patrick Smith uunet.ca!frumious!pat pat%frumious.uucp@uunet.ca