Open 9il opened 5 years ago
Thank you for letting me know.
I think we should use std.complex
instead of built-in complex types because build-in complex types are deprecated in the future.
However, lubeck use mir.blas and mir.lapack, and we may have to make some changes to these libraries.
Fortunately, cblas and lapack, which are used from mir.blas and mir.lapack, are able to handle std.complex
with some version switches (see: Ref1 and Ref2).
They have been planned for depreciation for a long time. However, std.complex is not well as builtin numbers. Especially for optimization with LDC. This version switches must not be used in mir ecosystem (including lubeck). They are defined for third side libraries and apps.
Lubeck can use both std.complex and built-in complex numbers with constraints like is(C: Complex!T) || mir.internal.utility.isComplex!C
and convert to native numbers to cal mir. std.complex and built-in complex numbers have the same payload.
OK, I see.
I will make a pull request which provides std.complex
interfaces.
These interfaces just convert from std.complex
to built-in types, as do casting pointer.
Also, I will rewrite the failed unittest to use std.complex
.
@k3kaimu, I disabled the unittest https://github.com/kaleidicassociates/lubeck/commit/c76f4f848641515a4611b1888d7c62b9adfc1812
DMD 2.084 and LDC 1.14 works