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@Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/>