Implement complex numbers

[boggle]

Complex numbers in C are implemented by passing real and imaginary part as two consecutive, unpadded floating point values via the stack (i.e. as length-2 array). This is similar for returned complex values - which is the catch, as tuples in rust are defined to have the same alignment behavior as records (cf spec). This means a (f32, f32) complex might suffer padding and is thus not suitable for implementing complex values. I see different ways to deal with this and would like comments on which is best

1. Implement native complex types (complex, c32, c64) in rust. Shouldn't be too hard but is a substantial language change,
2. Define tuple components to be stored consecutively (i.e. without padding/alignment),
3. Solve via annotation when declaration function prototypes in native mods,
4. Natively support c_vec (stack and heap allocated), or
5. Implement tuple-based wrappers in the runtime.

I'm tending to favor (1) though (3) and (4) might be desirable to have for other reasons.

[jckarter]

I don't know what Rust's abi rules are, but for every platform I know of, f32 is 32-bit aligned in C, so padding shouldn't be an issue. You may still need to have complex types be handled natively in order to deal with ABI differences between complex and structs—for example, on x86-64, _Complex long double return values are returned on the x87 stack, where as a struct of long doubles would be returned in memory. I think there's at least one x86-32 platform that also returns _Complex float and double values using a special rule (though I forget which). Perhaps you could handle the different ABI with a type attribute, though.

[leto]

One issue to think about is how Complex NaN will be handled. Will there be a real NaN and a separate Complex NaN? Or will you go the highlander "there can be only one NaN" route?

[graydon]

I'd wait on this until we see what happens on the typeclass work. Things like complex are prime candidates for overloaded arithmetic ops.

[kud1ing]

See #1227

[kud1ing]

Once we have interfaces/type classes, we should have a look at Haskell's hierarchy and do some cherrypicking.
For example Haskell's "Complex" implements the type class "RealFloat" http://www.haskell.org/onlinereport/basic.html#standard-classes

[boggle]

Yes, sure. Although I'd like to keep things a bit more simple than in Haskell. For now, typeclasses for integral and float types should suffice. Perhaps the float operations need to be split between a "full set" and those supported by floats and complex numbers alike. I'm really looking at libmath in that regard. Anyways to implement complex numbers, we may need ABI support for C's Complex type (implementing it ourselves is not a good option as it would hurt compatibility for bindings to C libraries).

[graydon]

I think we have almost enough machinery in the operator overloading space to implement this in the libraries now, using tuples and syntax extensions. Retagging as lib-related.

[boggle]

I am still opposed to doing that in the libraries. If we do not support the C complex type that will cause overhead when calling the lib math functions for complex numbers and in integration with numerical C code. I'd actually rather see rust have primitive complex types (c64, c128, similar to "go") that directly map on their C counterparts. This solution would be in line with what we do for floats and should make it easier to handle the ABI requirements of passing complex numbers to C functions.

[catamorphism]

Tagging RFC since there's a question of whether to do this in libraries or in the RTS.

[thestinger]

This has been implemented.