Thread overview
Complex numbers in lib?
Jul 28, 2020
sai
Jul 28, 2020
Guillaume Piolat
Jul 28, 2020
Seb
July 28, 2020
I remember the reason D has built in complex numbers is because it supposed to give correct results, as mentioned at the bottom here: https://digitalmars.com/d/1.0/cppcomplex.html

And the math checks out: https://run.dlang.io/is/b5eyuD

So I am curious why the complex class in the library was introduced and the builtin complex numbers are deprecated now?

And how to avoid errors like the above when using the complex library?

Thanks
Sai


July 28, 2020
On Tuesday, 28 July 2020 at 01:24:16 UTC, sai wrote:
> I remember the reason D has built in complex numbers is because it supposed to give correct results, as mentioned at the bottom here: https://digitalmars.com/d/1.0/cppcomplex.html
>
> And the math checks out: https://run.dlang.io/is/b5eyuD
>
> So I am curious why the complex class in the library was introduced and the builtin complex numbers are deprecated now?
>

I guess it's not considered a worthy use of D compiler engineers time.
The decision to remove them was taken long ago.
That said, we do use complex numbers and appreciate them, it would take work if they were to be actually removed... and that will probably happen.

But it's not really an efficiency or precision concern, efficient code using complex sometimes use split format, and this code is often vectorized anyway using SIMD.


July 28, 2020
On Tuesday, 28 July 2020 at 01:24:16 UTC, sai wrote:
> I remember the reason D has built in complex numbers is because it supposed to give correct results, as mentioned at the bottom here:

Hehe, my guess is that std.complex wasn't written by Walter and this special case was overlooked.

See also: https://github.com/dlang/phobos/blob/cd2ba0d2c378a893ec0eaefc57b87d0770a1990c/std/complex.d#L345-L347

> So I am curious why the complex class in the library was introduced

Supporting complex numbers requires a lot of work in the frontend.
For many features that D supports one needs to manually maintain special cases for complex numbers.
This has led to a lot of bugs and as complex numbers aren't very heavily used there are likely many which haven't surfaced yet.

A library solution provides almost the same interface and usability to the user. I guess the only missing thing is that it's a bit more verbose, but in theory the compiler could lower complex numbers to `std.complex` calls.

tl;dr:
- low usage of complex number to justify big complexity in compiler
- better maintainability as a library

The current philosophy is that everything that can be done in a library, should be done in a library to reduce the burden on the compiler.

> and the builtin complex numbers are deprecated now?

Technically they aren't deprecated yet (only discouraged to use). There was some work done in Phobos to support the deprecation PR for DMD (that's why you get the deprecation message when trying to print them), but the DMD deprecation PR stalled:

https://github.com/dlang/dmd/pull/7640

> And how to avoid errors like the above when using the complex library?

3i (builtin) and complex(0, 3) (library) are different types.

To avoid deprecation errors, the `complex` (library) and not the to-be-deprecated built-in types should be used.