multiplication of infinity by zero in Matlab Calculation

Hi,

I have a problem with the evaluation of an equation. My problem is that; one of the parts in the equation will result to infinity, and another part will result to zero. Then the product of them should give me zero BUT it gave me NAN. How I can solve this problem?

Thank you

[Star Strider]

Do you have the Symbolic Math Toolbox?

[Jamal Ahmad]

Yes I have.

[Roger Stafford]

@Jamal Ahmad. It should be noted that matlab does not decide this answer of a NaN. It is hard-wired into all computers which use the IEEE 754 floating point standard, which almost surely means your computer.

Answer 1

[the cyclist]

The product of 0 and infinity, mathematically, is not zero. It is indeterminate. That is why it gives you a NaN.

See, e.g., http://mathworld.wolfram.com/Indeterminate.html.

[Walter Roberson]

Right. One of the forms of argument is:

Suppose 0 * infinity = 0. Then divide through by the first term to obtain the form infinity = 0/0 . But is that true? If you consider x/x for any non-zero x, you get 1, so x/x is 1 in every closed compact set around x = 0, so the analytic of 0/0 is 1. But if infinity = 0/0 and 0/0 is analytically 1, then infinity =? 1 which is clearly false.

Now consider 0 * infinity = Q for any non-zero Q in the set of complex numbers (including reals). Is it possibly true? Well, divide through by Q to get

0/Q * infinity = 1

and 0/Q is 0 for all non-zero Q, so we have reached back to

0 * infinity = 1

so if that holds then it must also hold that 0 * infinity = Q for all non-zero Q. Clearly though it cannot be all of them simultaneously. We are now down to two cases:

• if 0 * infinity = 1 is provable, then 0 * infinity = Q is provable for non-zero Q, which would make the product of 0 and infinity indeterminate because it could be any non-zero value.
• if 0 * infinity = 1 is not provable, we are still left with the case of 0 * infinity = 0 (i.e., if Q were 0), which we found above has a conflict due to limit x->0 of x/x is 1 but would have to be infinity for 0 * infinity = 0 to hold...

[Iain]

I tend to find thinking of it easier in this way:

 Infinity = x/0, where x > 0.
 Infinity * 0 = 0 * x / 0, so you can now cancel the 0's, to get:

 Infinity * 0 = x

And, as 0 = -0,

 Infinity * 0 = -x

Infinity * 0, therefore, can be equal to anything.

[Jamal Ahmad]

thanks for the answers. I agree with you, but in my case I have different situation; for example I have exp(800) according to Matlab this is infinity. you know that zero * exp(800) should give me zero. but Matlab give me NAN.

[the cyclist]

Hard to be more specific without details, but one general rule in these situations is to apply log to all your terms.

[Jamal Ahmad]

OK Let me rephrase my question as the following: how can make Matlab not consider exp(1000) to be infinity? OR how to increase the precision of Matlab calculations to that range? this is because when you have infinity in Matlab you can't do anything with it. Many Thanks

[Walter Roberson]

Yes, it is possible to make MATLAB not consider exp(1000) to be infinity. What alternative value in the range

+/- 179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368

would you prefer?

[Jamal Ahmad]

good. how you do that? May be it is better to represent these large numbers interms of power. for example 1.234 10^50

[John D'Errico]

Walter, I think 42 somehow makes sense to me.

[Jamal Ahmad]

How?

[Iain]

You'll need to work in log-space.

 ln(exp(634)) = 634
 ln(exp(-632.2)) = -632.2
 634 + (-632.2) = 1.8
 exp(1.8) = exp(634)*exp(-632.2)

I doubt that there is an automatic way to work in logarithms rather than normal numbers.

Answer 2

[Patrik Ek]

The solution to this problem comes from the mathematical limit. 1/0 = inf is really a bit sloppy. If you remember how this was introduced in the mathematical analysis course you most likely took for many years ago you would see that the correct way to work with infinities is to work with limits for example,

lim x->0 a/x = inf, a<inf equ(1)

This is however in most cases seen as a general theorem, which allows you to write 1/0 = inf. Another way to express a<inf is to say that a is bounded. Otherwise it is unbounded, it can take any value larger than the largest real value. The same applies for,

lim x->inf b/x = 0; b<inf, equ(2)

since x->inf can be anything is could be larger than 0.00... so this still applies. But what happens if we have an expression?

lim x->0 ax*1/bx = a/b*x/x = a/b, equ(3)

You see that x cancels out and the answer is a/b. So the limit of two undefined values a*inf and 1/(b*inf) actually depends on the speed with which they go towards their limit.

The problem is that when matlab becomes inf or zero, matlab can not say how fast they apporach the limit. The obvious solution to that problem is to say that the limit can not be set, or the limit does not exist. Matlab then returns a nan for the cases

 inf/inf
 0/0
 0*inf

where equ(3) applies.

Answer 3

[Walter Roberson]

To make Matlab not consider exp(1000) to be infinity, overload the exp function for double datatype, and tell the function to return 42 instead of infinity when it detects that the absolute value of the argument exceeds realmax()

Good luck keeping from $%#@$'ing up other MATLAB code that expects infinity. Overloading a fundamental mathematical operation to make it lie is sure to be ... an interesting experience.

Answer 4

[David Young]

So x contains infinities and y contains zeros and we are willing to assume from knowledge of the earlier computation that when an infinity in x is multiplied by a zero in y, the correct answer is zero. Then it is reasonble to write:

z = x .* y;
z(isinf(x) & y == 0) = 0;

This replaces the NaNs that have been generated in this way by zeros.

[Walter Roberson]

Or more efficient,

z(y == 0) = 0;

If the inf might appear on either side,

z(~(x | y)) = 0;

[David Young]

Yes, indeed.

Answer 5

[Logan Capizzi]

If you want the NaN to be zero, you can do the following.

A(isnan(A)) = 0;

Answer 6

[Sri Vastava]

the cyclist wrote: The product of 0 and infinity, mathematically, is not zero. It is indeterminate. That is why it gives you a NaN.

The answer is infinity.

[Walter Roberson]

Sri Vastava: are you indicating that the product of 0 and infinity is infinity? We explore above why the answer is indeterminate, not infinity.

[David Goodmanson]

Hello Sri, It really is indeterminate.

as x -> 0,
    x -> 0  (of course)
  x^2 -> 0
  1/x is unbounded, -> inf
1/x^2 is unbounded, -> inf

now take three different expressions that are basically 0*inf:

as x-> 0
x^2 * (1/x)   = x -> 0
x   * (1/x^2) = 1/x is unbounded, -> inf
x   * (6/x)   = 6 -> 6

You can get any value that you want, so Matlab goes with the IEEE 754 standard and says NaN.

Answer 7

[Andrea Barletta]

I don't fully agree with previous comments on the meaning of the product between 0 and infinity. It is true that the result of 0*Inf is indeterminate when the latter is interpreted as the product between two limits - it simply doesn't make any sense if it is interpreted as a standalone expression. But the limit of 0*f(x) will always give 0, no matter where x and f(x) are going. In such case, in Matlab, we should get a genuine 0*Inf=0. Neglecting this exception may cause some issues in programming. Suppose that I have a function f defined as a function g truncated over a compact set A. Mathematically, the value f(x) should be zero for every x outside A, no matter how g is defined. But as Jamal Ahmad more or less remarked in one comment if we take

f=@(x) exp(x).*(abs(x)<=10);

and we evaluate x=1e3 we incorrectly get f(1e3)=NaN. Of course, IF using anonymous functions is not a necessity, one may overcome the problem by defining f as

function y=f(x)

if abs(x)<10
    y=exp(x);
else
    y=0;
end

end

But apparently truncation and anonymous functions don't like each other in Matlab...

[Walter Roberson]

"But the limit of 0*f(x) will always give 0, no matter where x and f(x) are going."

No, that is false. As far as limits are concerned, it does not matter whether you write 0*f(x) with f as a function, compared to if you write 0*(some expression in x) inline. If you do not know the behaviour of f(x) then for limit 0*f(x) the most you can say is piecewise(limit(f(x))=infinity or limit(f(x))=-infinity, undefined, 0)

"It is true that the result of 0*Inf is indeterminate when the latter is interpreted as the product between two limits - it simply doesn't make any sense if it is interpreted as a standalone expression."

but you then proceed to talk about 0*f(x) with respect to limits, rather than "as a standalone expression", whatever that means.

https://en.wikipedia.org/wiki/Indeterminate_form

https://www.quora.com/What-is-zero-times-infinity

[James Tursa]

To my reading, I think OP meant this when talking about the limit of 0*f(x)

limit ( 0 * f(x) ) = 0

for any infinite sequence of x as long as f(x) is finite at each point in the sequence.

But, I agree that MATLAB can hardly be expected to presume where the 0 and the inf came from when encountered in a downstream expression. So it doesn't make sense to expect MATLAB to produce a 0 result when it encounters 0*inf.

And, if one insists on a one-liner (I sure don't), then here is one very obfuscated way:

f=@(x) typecast(bitand(typecast(exp(x),'uint64'),typecast(int64(0-(abs(x)<=10)),'uint64')),'double');

(the if-then-else code is much preferred over this!)

[Walter Roberson]

If f(x) ∈ ℝ then 0*f(x) = 0. But ∞ ∉ ℝ

However, in MATLAB, inf has two different meanings, in a way.

One of them is ∞ -- the unbounded quantity of paradoxes. A deliberately coded inf or an inf produced as a result of an unbounded operation such as log(0) should indeed have the property that 0*inf is indeterminate.

The second meaning in MATLAB (and IEEE 754 arithmetic) is that floating point infinity is also used to stand in for "overflow produced by operations on finite numbers". Like factorial(171) or exp(710) is all operations on finite numbers but the result is just too big to fit. If there were a "finite overflow", that was distinguished from infinity, then "finite overflow" times 0 would be 0.

[John D'Errico]

On the face of it, were there two different infinities, that seems to help. But does it really?

The fact is, there is just as good an argument for the need to have TWO different zeros, one for a zero derived from an underflow, one for a true zero.

Depending on where the "zero" came from, there are different possible results we might then expect for any operation.

Worse yet, suppose we have a inf that results from a small overflow, and a zero resulting from a massive underflow? Must we retain information that tells how big of an underflow or overflow it was?

The point is, once you go down this road you end up in a spiral, one that cannot easily be resolved.

inf is inf, zero is zero, and that is where it must end.

[Andrea Barletta]

If f(x) ∈ ℝ then 0*f(x) = 0. But ∞ ∉ ℝ.

Take any real-valued function f defined on a sub-domain D of ℝ^n. Define g(x)=0*f(x)=0 for every x in D. Take x0 in the closure of D. Then g(x) -> 0 as x->x0. But I agree with James Tursa that Matlab cannot determine whether f is defined only on a sub-domain and whether x0 is in the closure of this sub-domain. However, it could in some cases, such as when g is obtained by truncating a polynomial, exp, log, or their combination.

[John D'Errico]

NO. Really MATLAB cannot determine how something arrived at an inf result, nor could/should it store that information anywhere. Yup, you got an inf there, but it was only a small inf. Be serious. As I said, inf is inf.

[Walter Roberson]

MATLAB is a procedural language, not an Analytical Geometry or Numeric Analysis language. MATLAB assumes that if it was important to you to have tested for infinities to validate the calculation then you would have commanded it to do so.

Remember, MATLAB does not even take care to reorder a set of numbers it is adding in order to minimize the round-off error. If you are expecting it to do so then you are using the wrong language.

[Andrea Barletta]

I don't see why it should be difficult to check, every time that an anonymous function is evaluated, if the defining expression is of the form (indicator function of A)*(composition, product or sum between functions belonging to a preset list of smooth and well behaved built-in functions). In this case every time that the function is evaluated outside A Matlab can safely return 0. You could say that it wouldn't be worth investing any effort on that, given that one can always use an if-else statement, but that's completely another story. Anyway, a "truncation operator" to be used within anonymous functions would be very much useful.

[Walter Roberson]

What might make sense could be to define false * inf as 0 . Not 0 in general, but logical(0) specifically.