[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Inf/Inf = NaN?
From: |
Ted Harding |
Subject: |
Re: Inf/Inf = NaN? |
Date: |
Thu, 17 Apr 1997 10:03:06 +0100 (GMT+0100) |
( Re Message From: John Utz )
>
> On my fake pentium-100 running FreeBSD-2.2-GAMMA and octave-2.0.5 compiled
> with gcc-2.7.2 i get the above result ( Inf/Inf = NaN ). Shouldn't this
> equal 1?
>
> I was thinking of hacking if(a==Inf)&&(b==Inf) result = 1 into my
> code, but this is not how i like to work.
>
> note, the specific operation is (Inf-foo)/(Inf+foo) where foo is a real
> positive int. This should be equal to 1, but...does the fact that i am
> performing operations on Inf cause the math to "throw up it's hands and
> surrender", so to speak?
As far as I know "Inf/Inf = NaN" since the beginning of time in octave.
The point about "NaN" is that it represents the indeterminate outcome of
an operation whose result is not defined or is not unique.
So inf*inf = inf, 1/inf = 0, 1*inf = inf, 1+inf = inf and 1-inf = -inf
are OK. But Inf itself is not a determinate entity but represents a
limiting concept. So Inf is indeterminate in so far as the limit of the
expression in which it occurs does not depend on the limits of the terms
in the expression.
For instance, as X -> inf, Y = X*X -> inf;
so, in the limit,
(X-foo)/(Y+foo) = inf/inf and
(Y-foo)/(X+foo) = inf/inf
but, in the limit, the first -> 0 but the second -> inf. Likewise
(a*X - foo)/(b*X + foo) -> a/b but " = inf/inf"
where a & b are anything. This is why "Inf/Inf" is indeterminate in
general and should be represented by "NaN".
Clearly what you have in mind for your calculation is the equivalent
of (X-foo)/(X+foo) -> 1 as X -> inf, but this is a special case of all the
possible limiting expressions that could correspond to inf/inf, which
between them lead to all possible results. So it's fine for you to write
code which says "if(a==Inf)&&(b==Inf) result = 1", provided you're only
dealing with cases like (X-foo)/(X+foo). But if you're dealing with
anything else then you should define "result" accordingly. The use of
"NaN" to flag an indeterminate result is very valuable, and the arithmetic
of "inf" should not be subverted by resolving the indeterminacy in a
particular way.
All the best,
Ted. (address@hidden)