[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Re: FW: Transcendental function tables: comments welcome!
On 2007-06-06 00:01:30 +1000, Peter Henderson wrote:
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?
See my message: 0 * (+inf).
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.
What I'm saying is that it is a possible way to regard +inf (based
on formal definitions).
+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.
A limit must be defined on a topological space. Here one has several
choices, each with their advantages and their drawbacks.
If the limit does not exist, return NaN. This holds
whether x is a real or integer.
The point is that the limit *does* exist on the floating-point numbers
with unbounded exponents.
Why would you choose sinpi(+inf) = NaN while pow(-1,+inf) = +1?
My answer is that your question is ill-posed,
It is very-well posed. I recall that the current draft says:
sinpi(+inf) = NaN *and* pow(-1,+inf) = +1
My question is: why this choice?
because it makes no sense at
all to define pow(-1,+inf) = +1.
It does make sense if you consider the floating-point numbers with
unbounded exponents.
The limit of -1^n, where n is an integer, does not exist as n tends
to infinity. pow(-1,+inf) must be NaN.
This is a possible choice (not my preferred one, though). But at least
it seems that we agree that the current draft is buggy.
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.
This is more than that. You have several floating-point algorithms
(e.g. FastTwoSum) that would no longer make sense on the arithmetic
of real numbers.
What is important is to preserve properties of the real valued
functions of real variables that we are approximating.
which is impossible. One has to make choices. Whatever the choices,
some properties will be preserved while other ones will be broken.
. . . 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.
Are you suggesting that pow(-1,x) should return NaN as soon as x
becomes "large enough", e.g. x > 2^53?
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.
I disagree. This is not necessarily an error. If you consider this
as an error, then you should also consider pow(-1,x) for x > 2^53
as an error.
--
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)