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