std.complex

[Lars T. Kyllingstad]

On Thursday, 2 January 2014 at 18:37:36 UTC, Ola Fosheim Grøstad 
wrote:
> On Thursday, 2 January 2014 at 11:37:22 UTC, Lars T. 
> Kyllingstad wrote:
>> I don't think we should worry too much about standards 
>> compliance. A library Complex type is quite different from a 
>> hardware floating-point type.
>
> Are you sure?

Not at all. ;)

I just think we should keep in mind why FP semantics are defined 
the way they are. Take 0.0*inf, for example.  As has been 
mentioned, 0.0 may represent a positive real number arbitrarily 
close to zero, and inf may represent an arbitrarily large real 
number. The product of these is ill-defined, and hence 
represented by a NaN.

0.0+1.0i, on the other hand, represents a number which is 
arbitrarily close to i. Multiplying it with a very large real 
number gives you a number which has a very large imaginary part, 
but which is arbitrarily close to the imaginary axis, i.e. 0.0 + 
inf i. I think this is very consistent with FP semantics, and may 
be worth making a special case in std.complex.Complex.


> Sometimes you need to translate an algorithm, you don't 
> understand the inner workings of, from a codebase/cookbook. If 
> std.complex differs from the most used c++/fortran 
> implementations people will be confused, and you also end up 
> having (machine translated) algorithm libraries each supplying 
> their own complex type. Use 3 different libraries and you have 
> to deal with 3 different complex types.

I agree, but there is also a lot to be said for not repeating old 
mistakes, if we deem them to be such.