Infinity and Undefined

[Richard B. Kreckel]

On Sun, 4 Nov 2001, Pearu Peterson wrote:
[...]
> > Perhaps I'll just pave the way with Infinity and Undefined. I've never 
> > actually dealt with complex infinity, so I'm sure someone more familiar with 
> > the concept would do this better.
> 
> In past I tried to introduce the Infinity and Undefined concepts to GMP
> in its Python layer (gmpy). I also tried to avoid complex infinity stuff
> but it is not quite possible. For example, how would you deal with
> 	<complex number> * Infinity?
> 
> Another confusing stuff is arithmetics with Infinities. For example,
> consider
> 	2 * Infinity + sqrt(-1) * Infinity
> How would you simplify such expression? There are many seemingly
> reasonable approaches that, unfortuantely, lead to different results. E.g.
>         2 * Infinity + sqrt(-1) * Infinity ->
>         (2 + sqrt(-1)) * Infinity
> or
> 	Infinity + sqrt(-1) * Infinity -> (1 + sqrt(-1)) * Infinity.
> And both results may be incorrect as Infinities may have different 
> weights.

This is a very valid example and in my opinion the only way out of this is
to return Undefined if the coefficients are not either on the real axis
alone or the imaginary axis alone.  They also need to have the same sign,
of course.  Doesn't the example fall into the same category as
(Infinity - Infinity), which should be Undefined, too?

[...]
> My friendly suggestion for you would be to first study these different
> approaches and propose a complete specification of the extended number
> model before trying to actually implement its support for GiNaC. This
> specification should include at least the following tables:
> 	<operation>     | <finite number> | Infinity | Undefined
>         --------------------------------------------------------
>         <finite number> | <result?>       | <result?> | <result?>
>         Infinity        | ...
>         Undefined       | ...
> where <operation>s are +,-,*,/,**,elementary functions.
> These table may have more rows (e.g. PlusInfinity, MinusInfinity,
> ComplexInfinity, SignInfinity, ImaginaryUnit, ComplexNumber,
> ImaginaryNumber, FieldNumber, etc) depending on the approach.

Uh, oh, while such a table would be helpful in understanding the issues
involved, I think we shouldn't bother with all of the rows you are
suggesting.  BTW, what's a FieldNumber?

Regards
     -richy.
-- 
Richard B. Kreckel
<Richard.Kreckel at GiNaC.DE>