std.complex
Lars T. Kyllingstad
public at kyllingen.net
Thu Jan 2 15:43:45 PST 2014
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.
More information about the Digitalmars-d
mailing list