Bug 10881 – Support %f formatting for a std.complex.complex

In dmd 2.064alpha you have to use %s to print a std.complex.complex: import std.stdio: writefln; import std.complex: complex; void main() { auto c = complex(1.2, 3.4); writefln("%s", c); auto gaussianInteger = complex!int(1, 2); writefln("%s", gaussianInteger); } But today we can have something better so I suggest to modify the toString of those complex structs to support a basic floating point formatting too (here 3.2f is used for both parts of the complex number): auto c = complex(1.2, 3.4); writefln("%3.2f", c); If you are using the uncommon Gaussian integers then probably you have to use %d: auto gaussianInteger = complex!int(1, 2); writefln("%10d", gaussianInteger); If you want to format differently the two parts of a complex number, then a syntax similar to array formatting could be supported, but this is less important because I think it's a less common need, and could be left for a successive enhancement: writefln("%(%1.2f, -1.2f%)", c);

Do we actually support complex!int today? From looking at the code, it seems to only support floating-point types.

Heh. Seem auto-promotion hid the fact that gaussian integers aren't actually supported: import std.complex; void main() { auto x = complex!int(1,2); pragma(msg, typeof(x)); // prints Complex!double }

(In reply to comment #1) > Do we actually support complex!int today? From looking at the code, it seems to > only support floating-point types. I see. I will open another issue on this. I see two possibilities: support gaussian integers too, or statically refuse code like "complex!int(1, 2)".

(In reply to comment #3) > I see. I will open another issue on this. I see two possibilities: support > gaussian integers too, or statically refuse code like "complex!int(1, 2)". "Complex!int(1, 2)" is refused. The "complex!int(1, 2)" is not refused, but perhaps there is not simple way to forbid that.

Another related issue is how field widths should be handled by the formatting functions. Currently, toString supports a custom print format (it doesn't integrate properly with the present std.format, but don't worry about that -- I have the fix for that already). But it produces unexpected results: complex(1.2, 3.4).toString(null, "%5.2f") produces " 1.00+ 2.00i", because the format spec is just propagated to the real/imaginary parts of the number. This is unexpected because from the user's POV, the field width specifies the width for the entire complex number, not the individual parts. I'd expect the format "%5.2f" should mean field width of *entire* complex number is 5, with 2 digits precision after the decimal point. So the output should be "1.00+2.00i" because the resulting string exceeds the specified field width. If the format was "%5.0f", I'd expect the output to be " 1+2i" (1 space padding to fill up to field width of 5), but the current result is " 1+ 2i".

(In reply to comment #5) > because the format spec > is just propagated to the real/imaginary parts of the number. This is > unexpected because from the user's POV, the field width specifies the width for > the entire complex number, not the individual parts. In my request I wrote: > (here 3.2f is used for both parts of the complex number): I meant that each single floating point value is formatted independently with 3.2f. This means my POV was different from the one you have assumed. I don't know what's the best solution for this, but I think my request is simpler, just format the two values separately, this means calling and re-using the usual floating point formatting logic two times.

This is a small use case: void main() { import std.stdio, std.complex, std.math; alias C = complex; immutable x = 2 ^^ 0.5 / 2; immutable M = [[C(x, 0.0), C(x, 0.0), C(0.0, 0.0)], [C(0.0, -x), C(0.0, x), C(0.0, 0.0)], [C(0.0, 0.0), C(0.0, 0.0), C(0.0, 1.0)]]; writefln("[%([%(%s, %)],\n %)]]", M); } It prints: [[0.707107+0i, 0.707107+0i, 0+0i], [0-0.707107i, 0+0.707107i, 0+0i], [0+0i, 0+0i, 0+1i]] But I'd like the columns to be aligned vertically, to increase the readability of the matrix.

Hmm. OK, in that case, the current behaviour of the code already does what you want. :) All that's needed is to support %f directly in writefln.

Commit pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/627d178f87423ba8b6059216ae1ca3fc8a2b2f29 Merge pull request #1516 from quickfur/complex_format Fix issue 10881: support writefln("%f") of complex numbers

(In reply to comment #10) > Commit pushed to master at https://github.com/D-Programming-Language/phobos Now using this formatting string, for the given matrix: "[%([%(%1.3f, %)],\n %)]]" It outputs: [[0.707+0.000i, 0.707+0.000i, 0.000+0.000i], [0.000-0.707i, 0.000+0.707i, 0.000+0.000i], [0.000+0.000i, 0.000+0.000i, 0.000+1.000i]]

(In reply to comment #11) > (In reply to comment #10) > > Commit pushed to master at https://github.com/D-Programming-Language/phobos > > Now using this formatting string, for the given matrix: > "[%([%(%1.3f, %)],\n %)]]" > > It outputs: > > [[0.707+0.000i, 0.707+0.000i, 0.000+0.000i], > [0.000-0.707i, 0.000+0.707i, 0.000+0.000i], > [0.000+0.000i, 0.000+0.000i, 0.000+1.000i]] For anybody reading this on forum.dlang.org: please view the entry on the bug tracker: There *is* a space that prefixes those lines, and they are all actually perfectly aligned.