From: Tim Prince on
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
<robert.corbett(a)> wrote in message news:92fe8783-34a5-4c55-8b91-335a4fa31046(a)
| On Jan 18, 6:17 am, Arjen Markus <arjen.markus...(a)> 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
"Dan Nagle" <dannagle(a)> wrote in message news:hj732m$hnv$1(a)
| Hello,
| On 2010-01-20 05:42:25 -0500, "Les Neilson" <l.neilson(a)> said:
| > "Simon Geard" <simon(a)> wrote in message
| > news:hj6krv$nj0$1(a)
| >> 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
In article <PHZ5n.2538$pv.9(a)>,
"robin" <robin_v(a)> 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

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
robin wrote:
> "Richard Maine" <nospam(a)see.signature> wrote in message news:1jcmdwz.q2w7y5105qdsiN%nospam(a)see.signature...
> | 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...