std.complex

[Andrei Alexandrescu]

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