Infinity and Undefined

Douglas Gregor gregod at cs.rpi.edu
Sat Nov 3 21:45:44 CET 2001


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

Precisely the case that has caused me the most problems :).  There are 
annoying little subcases as well, like Infinity + Pi*Infinity -> Infinity. 
Here we're stuck calling evalf() on the constant Pi to determine that it is 
positive. 

> May I suggest to also include CInfinity (like Mma's
> ComplexInfinity)?  That would be very useful for poles in the complex
> domain.

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.

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

Yes, I believe adding a special class for each would be the best option. If 
nothing else, it will eliminate a dynamic_cast and an integer comparison when 
testing for Infinity or Undefined.

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

I expected this comment  :)

I'll do whatever I can to ensure that this addition does not cause a sizeable 
performance degradation.

	Doug



More information about the GiNaC-devel mailing list