I believe that computing with "inf" as a number is too mathematically murky
to give reasonable results except in a very few cases. If you treat "inf"
as a sort if shorthand for "limit(<expr>,x,inf)" then almost any expression
involving two or more infs should produce und. As far as I know, IEEE754
requires than any expression involving NaN (und) return NaN. So far so
good. Here are some "reasonable" results:
n+inf -> inf (n is a fixed real number); for example: 3.6+inf -> inf
n*inf -> inf (n>0)
n^inf -> inf (n>1)
inf + inf -> inf
inf * inf -> inf
inf ^ inf -> inf
and similar rules with minf.
I think that every other expression with inf, including 1^inf, 0*inf, should
return und. I don't even like saying n/inf -> 0 (n non zero); to my mind
it's an abuse of the concept of division.
Oh, and by the way, here's Knuth et al ("Concrete Mathematics") on 0^0:
"Some textbooks leave the quantity 0^0 undefined, because the functions x^0
and 0^x have different limiting values when *x* decreases to 0. But this is
a mistake. We must define x^0=1 for all *x*, if the binomial theorem is to
be valid when *x*=0, *y*=0, and/or *x*=-*y*. The theorem is too important to
be arbitrarily restricted! By contrast, the function 0^x is quite
unimportant."
Here's part of a Maple session involving infinity:
> infinity+infinity;
infinity
> infinity-infinity;
undefined
> infinity*infinity;
infinity
> infinity^infinity;
infinity
> infinity/infinity;
undefined
> 0*infinity;
undefined
> 0^0;
1
> 1^infinity;
1
> 1.0^infinity;
1.
> 1/infinity;
0
> 0.2^infinity;
0.
-Alasdair