On 11/25/13 12:18 AM, Joseph Rushton Wakeling wrote:
On 25/11/13 00:35, Andrei Alexandrescu wrote:
How many special cases are out there?
Well, if you have two complex numbers, z1 and z2, then
(z1 * z2).re = (z1.re * z2.re) - (z1.im * z2.im)
and
(z1 * z2).im = (z1.im * z2.re) + (z2.re * z1.im)
So you have to do if's for all four of z1.im, z2.re, z2.re and z1.im,
and then you have to decide whether you override the apparent IEEE
default just for the case of (re * im) or whether you do it for everything.
I mean, it feels a bit weird if you allow 0 * inf = 0 when it's real
part times imaginary part, but not when it's real part times real part.
Doesn't sound all that bad to me. After all the built-in complex must be
doing something similar. Of course if a separate imaginary type helps
this and other cases, we should define it.
It sort of does. If you multiply something that goes to 0 with
something that
goes to infinity it could go either way.
I'm not sure I follow. I mean, if you have two sequences {x_i} --> 0
and {y_i} --> inf, then sure, the sequence of the product {x_i * y_i}
can go either way. But if you just think of 0 as a number, then
0 * inf = 0 * lim{x --> inf} x
= lim{x --> inf} (0 * x)
= lim{x --> inf} 0
= 0
Heh, no need for the expansion :o). Zero is zero.
Or am I missing something about how FP numbers are implemented that
either makes it convenient to define 0 * inf as not-a-number or that
means that there are ambiguities that don't exist for "real" real numbers?
Well 0 in FP can always be considered a number so small, 0 was the
closest representation. But I'm just speculating as to whether that's
the reason for the choice.
Andrei
