Maths constants
in [Fortran]
|
From: Tim Prince on 21 Jan 2010 09:02 glen herrmannsfeldt wrote: > > How big do you mean by big? As I said, Intel uses 2.**64 for IA32. > I think you're referring to the x87 firmware sin/cos, which returns the argument when its absolute value exceeds 2**64. It also sets status bits, giving a library multiple ways of catching it. That would no longer be used by many compilers, unless ia32/387 code generation and library is selected.
From: robin on 21 Jan 2010 09:40 <robert.corbett(a)sun.com> wrote in message news:92fe8783-34a5-4c55-8b91-335a4fa31046(a)a6g2000yqm.googlegroups.com... | On Jan 18, 6:17 am, Arjen Markus <arjen.markus...(a)gmail.com> wrote: | | > More importantly perhaps, the results of your program might | > depend on the quality of the library routines that you would | > be using. | | I would like to second this. Although there are many | compilers that have trouble converting floating-point | constants to internal values with complete accuracy, | your odds are much better with literal constants than | with transcendental functions. If you can't trust the builtin functions, what can you trust?
From: robin on 21 Jan 2010 09:40 "Dan Nagle" <dannagle(a)verizon.net> wrote in message news:hj732m$hnv$1(a)news.eternal-september.org... | Hello, | | On 2010-01-20 05:42:25 -0500, "Les Neilson" <l.neilson(a)nospam.co.uk> said: | | > "Simon Geard" <simon(a)whiteowl.co.uk> wrote in message | > news:hj6krv$nj0$1(a)news.eternal-september.org... | | | >> Which makes me wonder why there aren't intrinsic parameters to go with | >> intrinsic functions. Presumably they have been suggested for possible | >> inclusion in f90, 95, 2003 and 2008 but rejected. | | > The first difficulty would be specifying a *finite* list of constants | > (there are rather a lot across the sciences that I can think of and | > presumably plenty more of which I am unaware or have forgotten - | > someone's favourite constant being left out might cause a diplomatic | > incident!) | > | > Then there are those constants which are continually being refined to | > greater accuracy. Compiler vendors have enough to do without having to | > keep track of changes to the accepted value for something. | | Leaving aside the issue of mathematical versus physical | constants, it has been considered, and rejected. | | The issue was the difficulty of anticipating the intended use | of the constant. Is it to be used as a threshold, or a sentinel, | or a conversion factor, or something else? That is, of course, irrelevant. When was pi needed for a threshold, sentinel, or whatever. A constant only needs to be stored as accurately as it can be.
From: Ron Shepard on 21 Jan 2010 13:12 In article <PHZ5n.2538$pv.9(a)news-server.bigpond.net.au>, "robin" <robin_v(a)bigpond.com> wrote: > | For a value 1 bit smaller in magnitude than -1.0, the acos ought to be > | off by quite a bit. > > If a Fortran compiler cannot store -1 accurately and precisely, > then you'd have something else to worry about! It seems that people aren't really reading the posts in this thread. Or maybe they don't understand what is being said. What Richard is saying is that there are a large number of floating point values that satisfy -1.0=COS(theta) for theta near PI. This is because the exact derivative is zero and it is a second-order function in that neighborhood. Any floating point value in the range PI-sqrt(eps) to PI+sqrt(eps) should satisfy the equation. You would expect that the ACOS intrinsic returns one of these values. That is not required by the standard, of course, but that is a different issue. But which one is returned is still an issue. In some cases you might want ACOS to return the one closest to PI, in other cases you might want it to return the one closest to PI that is less than PI, in other cases you might want it to return the smallest one of these floating point numbers (which is about sqrt(eps) smaller than Pi). Without extra information given to it, the math library cannot possibly know which of these values to return, so it must return one of them. If it isn't the one you want, then your program will be using the wrong value. There are other mathematical expressions that do not suffer from the small-derivative/second-order problem. 2.0*ASIN(1.0) is not one of them. This has the same kind of problems as ACOS(-1.0). 4.0*ATAN(1.0) is the most common expression among programmers. This is because the expression TAN(theta) near theta=0.25 has a nonzero first derivative, so there are only a few values for the floating point theta that satisfy the equation (two values for binary exponents). You still must determine which of those values to use, but you have fewer possibilities to choose from. I find it hard to believe that someone has been programming for 30 years and has never seen this expression used for PI (or questioned why it is preferred over the alternatives). In the end, I tend to use literals for these kinds of constants. These can be obtained to arbitrary precision from any number of sources. I think it is a good idea for a program to access the same list of constants (rather than recomputing them in different parts of the program). This is because you can get into situations where two values for the same constant are in conflict. For example, suppose you are testing convergence thresholds for some procedure, and the computation is done with one value, but the convergence test is done with another value. You might get in a situation where it appears that convergence is never achieved, or that convergence is thought to have occurred one iteration too soon. And if this list of values needs to be changed (either physical constants are changed, or more precision needs to be added for mathematical constants), then it needs to be done in only one place. $.02 -Ron Shepard
From: Carlie Coats on 21 Jan 2010 13:13
robin wrote: > "Richard Maine" <nospam(a)see.signature> wrote in message news:1jcmdwz.q2w7y5105qdsiN%nospam(a)see.signature... [snip...] > | For a value 1 bit smaller in magnitude than -1.0, the acos ought to be > | off by quite a bit. > > If a Fortran compiler cannot store -1 accurately and precisely, > then you'd have something else to worry about! Sometimes you do. Various vector machines come to mind... |