www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - complex number support

reply Walter Bright <newshound2 digitalmars.com> writes:
It's becoming clear that I cannot avoid supporting complex numbers in the code 
generator for AArch64:

1. deprecating creal and use std.complex instead doesn't help since we need to 
support old code

2. C has complex real and imaginary real types, which need to be supported as
well.

I'm giving up and am just going to support complex types in the code generator.
Feb 03
next sibling parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 04/02/2026 6:14 PM, Walter Bright wrote:

 It's becoming clear that I cannot avoid supporting complex numbers in 
 the code generator for AArch64:
 
 1. deprecating creal and use std.complex instead doesn't help since we 
 need to support old code
 
 2. C has complex real and imaginary real types, which need to be 
 supported as well.
 
 I'm giving up and am just going to support complex types in the code 
 generator.


I'm reminded of a certain comment you once made about extern(C++) about 
how it was not worth the effort, until it was a few years later.

Both (u)cent and float16 are in the same boat.
Feb 03
parent Walter Bright <newshound2 digitalmars.com> writes:
On 2/3/2026 9:22 PM, Richard (Rikki) Andrew Cattermole wrote:

 Both (u)cent and float16 are in the same boat.


ucent and float16 are a much simpler problem.
Feb 04
prev sibling next sibling parent reply Iain Buclaw <ibuclaw gdcproject.org> writes:
On Wednesday, 4 February 2026 at 05:14:52 UTC, Walter Bright 
wrote:

 It's becoming clear that I cannot avoid supporting complex 
 numbers in the code generator for AArch64:

 1. deprecating creal and use std.complex instead doesn't help 
 since we need to support old code

 2. C has complex real and imaginary real types, which need to 
 be supported as well.

 I'm giving up and am just going to support complex types in the 
 code generator.


I've mentioned this before.  I might be open to reintroducing 
complex into the language as `__complex(float)` et al. so that it 
falls into the specialized category of types that aren't 
guaranteed to always be supported (whilst at the same time 
freeing up the old keywords to use as an identifier)

We already have the means to test whether `__vector(T)` is 
supported on a given target, the same style hooks can be used for 
`__complex(T)`.
Feb 04
next sibling parent reply Quirin Schroll <qs.il.paperinik gmail.com> writes:
On Wednesday, 4 February 2026 at 16:58:42 UTC, Iain Buclaw wrote:

 On Wednesday, 4 February 2026 at 05:14:52 UTC, Walter Bright 
 wrote:

 It's becoming clear that I cannot avoid supporting complex 
 numbers in the code generator for AArch64:

 1. deprecating creal and use std.complex instead doesn't help 
 since we need to support old code

 2. C has complex real and imaginary real types, which need to 
 be supported as well.

 I'm giving up and am just going to support complex types in 
 the code generator.


 I've mentioned this before.  I might be open to reintroducing 
 complex into the language as `__complex(float)` et al. so that 
 it falls into the specialized category of types that aren't 
 guaranteed to always be supported (whilst at the same time 
 freeing up the old keywords to use as an identifier)

 We already have the means to test whether `__vector(T)` is 
 supported on a given target, the same style hooks can be used 
 for `__complex(T)`.


Please don’t miss `__imaginary`.

It wouldn’t be too terrible if object.d had this:
```d
version(ImaginarySupport)
{
     alias ifloat  = __imaginary(float);
     alias idouble = __imaginary(double);
     alias ireal   = __imaginary(real);
}
version(ComplexSupport)
{
     alias cfloat  = __complex(float);
     alias cdouble = __complex(double);
     alias creal   = __complex(real);
}
```
Feb 04
parent jmh530 <john.michael.hall gmail.com> writes:
On Wednesday, 4 February 2026 at 17:19:36 UTC, Quirin Schroll 
wrote:

 [snip]

 It wouldn’t be too terrible if object.d had this:
 ```d
 version(ImaginarySupport)
 {
     alias ifloat  = __imaginary(float);
     alias idouble = __imaginary(double);
     alias ireal   = __imaginary(real);
 }
 version(ComplexSupport)
 {
     alias cfloat  = __complex(float);
     alias cdouble = __complex(double);
     alias creal   = __complex(real);
 }
 ```


What about `core.complex`?
Feb 04
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 2/4/2026 8:58 AM, Iain Buclaw wrote:

 I've mentioned this before.  I might be open to reintroducing complex into
the 
 language as `__complex(float)` et al. so that it falls into the specialized 
 category of types that aren't guaranteed to always be supported (whilst at the 
 same time freeing up the old keywords to use as an identifier)
 
 We already have the means to test whether `__vector(T)` is supported on a
given 
 target, the same style hooks can be used for `__complex(T)`.


Complex will always have to be supported because of C.

The vector types have a lot of specific code generator support. I have deferred 
investigating how to implement it for AArch64 until everything else is working.
Feb 04
prev sibling parent reply Quirin Schroll <qs.il.paperinik gmail.com> writes:
On Wednesday, 4 February 2026 at 05:14:52 UTC, Walter Bright 
wrote:

 It's becoming clear that I cannot avoid supporting complex 
 numbers in the code generator for AArch64:

 1. deprecating creal and use std.complex instead doesn't help 
 since we need to support old code

 2. C has complex real and imaginary real types, which need to 
 be supported as well.

 I'm giving up and am just going to support complex types in the 
 code generator.


Having a built-in complex number types was a major selling point 
when I started looking into D ~10 years ago.
Feb 04
next sibling parent Iain Buclaw <ibuclaw gdcproject.org> writes:
On Wednesday, 4 February 2026 at 17:15:49 UTC, Quirin Schroll 
wrote:

 On Wednesday, 4 February 2026 at 05:14:52 UTC, Walter Bright 
 wrote:

 It's becoming clear that I cannot avoid supporting complex 
 numbers in the code generator for AArch64:

 1. deprecating creal and use std.complex instead doesn't help 
 since we need to support old code

 2. C has complex real and imaginary real types, which need to 
 be supported as well.

 I'm giving up and am just going to support complex types in 
 the code generator.


 Having a built-in complex number types was a major selling 
 point when I started looking into D ~10 years ago.


I did the benchmarks with GDC way back when. `std.complex` was 
just as, or more performant than the built-in types - this can be 
easily explained as many complex operations are not _actually_ 
supported in hardware, so become an opaque library call like 
[__muldc3](https://compiler-explorer.com/z/nx5qEGnfs).

The only thing lost was ABI compatibility, hence the special enum 
types that were added as the compromise.
Feb 04
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 2/4/2026 9:15 AM, Quirin Schroll wrote:

 Having a built-in complex number types was a major selling point when I
started 
 looking into D ~10 years ago.


I'm interested in your reasons!
Feb 04