Infinity and Undefined

[Richard B. Kreckel]

On Fri, 2 Nov 2001, Douglas Gregor wrote:
>   I'm currently extending GiNaC to be used for symbolic range propagation. 
> While the specifics of the extensions are likely not interesting to most 
> users, I do find that I need to handle both Infinite and Undefined values in 
> a sensible manner. I'll describe the approach I've taken thus far and would 
> appreciate feedback.
>   
>   Including Infinity and Undefined within GiNaC seems to weed its way into 
> many areas of the code. For instance, when we have two expair's x and y, we 
> assume that if x->rest == y->rest we can combine the coefficients. Clearly 
> this doesn't hold when we consider Infinity or Undefined, so we end up with a 
> large number of special-case branches when we see Infinity or Undefined in an 
> expression. This happens in quite a few places.
> 
>   My current approach is to defined GiNaC::constant values for Infinity and 
> Undefined, and include functions to quickly check if an expression is the 
> Infinity or Undefined constant. From there we just need to find all of the 
> required special cases...
> 
>   Again, and feedback would be appreciated. I've only been using GiNaC for a 
> short while, and perhaps there are tricks that could make this addition go 
> more smoothly.

Cool, you understand and appreciate the problem.  So, what advice could we
give you?  ;-)

It is clear that those two constants can easily be introduced but there is
some amount of work to be done to make them behave consistently, like
Infinity+Infinity -> Infinity, but Infinity-Infinity -> Undefined (or
fail?).  May I suggest to also include CInfinity (like Mma's
ComplexInfinity)?  That would be very useful for poles in the complex
domain.

Also, I don't know if class constant is appropiate for this.  They expect
to be evalf()'ed at some point, don't they?  Perhaps adding a special
class for each of them would be more appropiate?  I really don't know
right now...

My main concern is that one has to take some care when wiring that into
expairseq, add, mul, power, etc.  When the logic is inserted at the wrong
place this could lead to a performance downgrade that is too large to be
acceptable.  Many calculations don't need these constants and we do not
want to penalize them.  I am sure it can be done in a performant way.

Happy hacking
          -richy.
-- 
Richard B. Kreckel
<Richard.Kreckel at Uni-Mainz.DE>
<http://wwwthep.physik.uni-mainz.de/~kreckel/>