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