Infinity and Undefined

[Pearu Peterson]

On Sat, 10 Nov 2001, Richard B. Kreckel wrote:

> On Sun, 4 Nov 2001, Pearu Peterson wrote:

> > 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?

Sure. However one could extend your rule to:

      a*Inf + b*Inf -> (a+b)*Inf  iff a,b are complex
                                  numbers with Arg(a)==Arg(b)
                    -> Undefined  in all other cases.

> [...]
> > 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.  

Absolutely right. The contents of rows depends on the approach one
chooses.

> BTW, what's a FieldNumber?

I was thinking of quaternions (though they form skew field). However
introducing such objects to GiNaC may not be simple. And I am not sure if
you are interested in such an extension.

Regards,
	Pearu