[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Re: FW: Transcendental function tables: comments welcome!
Vincent Lefevre wrote:
On 2007-06-03 14:56:07 +1000, Peter Henderson wrote:
Vincent Lefevre wrote:
.
.
.
Really, the current definition of the infinity in the standard is buggy.
Alright, I'll bite. In what way? Could you give me an example?
.
.
.
First, more precisely, for the same reason that +Inf
can be regarded as a (large) positive integer, +Inf can be regarded
as a (large) positive even integer
Yes, all large floating point numbers are even integers, but this does
not mean +inf is. +inf represents infinity, which in IEEE arithmetic
means that the value of f(+inf) is the limit of f(x) as x tends to
infinity, if the limit exists. If the limit does not exist, return
NaN. This holds whether x is a real or integer.
Why would you choose sinpi(+inf) = NaN while pow(-1,+inf) = +1?
My answer is that your question is ill-posed, because it makes no sense
at all to define pow(-1,+inf) = +1. The limit of -1^n, where n is an
integer, does not exist as n tends to infinity. pow(-1,+inf) must be NaN.
In fact the whole idea of using a function such as sin(x), or sinpi(x)
with large values of x in floating point is suspect. Under what
possible circumstances would one want sinpi(x) for only (some) positive
integers. In the case of sinpi(x) it is sufficiently simple to assign
the exact value for large x, similiarly for cospi(x) etc., that this is
the best solution. But in what conceivable circumstances can it matter
what value sin(x) has for large flaoting point x. All one can
legitimately expect is that -1 <= sin(x) <= +1 and that relations such
as sin(x)^2+cos(x)^2 = 1. If this is not enough, then your program is
going to fail.
If floating point numbers are being used to represent integer arguments, which
only makes sense if the processor has no native integer format,
Of course, this is completely wrong in IEEE 754,
I stand corrected on this.
.
.
.
* Some functions are available on floating-point numbers only
(e.g. pow in ISO C99).
This is what started my involvement in this discussion. The opinion
that in the case of pow, a specialised function x^n, where x is floating
point and n integer, should be provided.
.
.
.
Well, the reason of taking the limit on the floating-point numbers was
not that floating-point numbers could be used to represent integers.
It was probably to preserve properties in case of overflow,
The reason this is wrong is that the purpose of floating point is to
enable us to approximate calculations involving real numbers. What is
important is to preserve properties of the real valued functions of real
variables that we are approximating.
.
.
.
If you mean that the purpose of infinity is to detect errors, this
is not the reason, since 1/+Inf gives 0: with a common operation,
you lose the error condition!
Which is a common objection to having infinity arithmetic. If this is
not the behaviour you want, then you have to test for infinity before it
can disappear.
.
.
.
. . . the problem will rectify itself in useful manner.
That's precisely the reason why it can be better to make pow(-1,+Inf)
return +1 instead of NaN.
But if you are calculating x^n for n so large that consecutive integers
can no longer be represented, then you are almost certainly producing
nonsense. All your monic polynomials tend to +infty as x tends to
-infty, even if you are trying to evaluate an odd order polynomial. In
fact, you should not be able to even ask for pow(-1,+inf).
pow(-1,+inf)=+1 hides your errors. It is doing you no favour.
Regards,
Peter Henderson