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.
