On Sat, 10 Nov 2001, Richard B. Kreckel wrote:
On Sun, 4 Nov 2001, Pearu Peterson wrote:
Another confusing stuff is arithmetics with Infinities. For example, consider 2 * Infinity + sqrt(-1) * Infinity How would you simplify such expression? There are many seemingly reasonable approaches that, unfortuantely, lead to different results. E.g. 2 * Infinity + sqrt(-1) * Infinity -> (2 + sqrt(-1)) * Infinity or Infinity + sqrt(-1) * Infinity -> (1 + sqrt(-1)) * Infinity. And both results may be incorrect as Infinities may have different weights.
This is a very valid example and in my opinion the only way out of this is to return Undefined if the coefficients are not either on the real axis alone or the imaginary axis alone. They also need to have the same sign, of course. Doesn't the example fall into the same category as (Infinity - Infinity), which should be Undefined, too?
Sure. However one could extend your rule to: a*Inf + b*Inf -> (a+b)*Inf iff a,b are complex numbers with Arg(a)==Arg(b) -> Undefined in all other cases.
[...]
My friendly suggestion for you would be to first study these different approaches and propose a complete specification of the extended number model before trying to actually implement its support for GiNaC. This specification should include at least the following tables: <operation> | <finite number> | Infinity | Undefined -------------------------------------------------------- <finite number> | <result?> | <result?> | <result?> Infinity | ... Undefined | ... where <operation>s are +,-,*,/,**,elementary functions. These table may have more rows (e.g. PlusInfinity, MinusInfinity, ComplexInfinity, SignInfinity, ImaginaryUnit, ComplexNumber, ImaginaryNumber, FieldNumber, etc) depending on the approach.
Uh, oh, while such a table would be helpful in understanding the issues involved, I think we shouldn't bother with all of the rows you are suggesting.
Absolutely right. The contents of rows depends on the approach one chooses.
BTW, what's a FieldNumber?
I was thinking of quaternions (though they form skew field). However introducing such objects to GiNaC may not be simple. And I am not sure if you are interested in such an extension. Regards, Pearu