How to Initialize Complex Numbers

[void main]

I'm rather new to complex numbers in C and was wondering, how do I
initialize a complex variable properly if the imaginary part is 0.

I tried

--------
#include <complex.h>

float complex c = 1.0f;
--------

and was told:

Error ctest.c: 3 invalid initialization type; found 'float' expected 'struct long double _Complex'

--------
#include <complex.h>

float complex c = 1.0f + I * 0.0f;
--------

and

--------
#include <complex.h>

float complex c = 1.0f + 0.0f * I;
--------

but both got me

Error c:\tests\clc\ctest.c 3 Compiler error (trap). Stopping compilation

What am I doing wrong?

[Dann Corbit]

"void main" <nos...@nospam.invalid> wrote in message
news:6138768.C...@aioe.org...

According to a sample in the C99 standard:
24 EXAMPLE 1 Provided that <complex.h> has been #included, the declarations
int i = 3.5;
complex c = 5 + 3 * I;

define and initialize i with the value 3 and c with the value 5. 0 + i3. 0.

So I think you are doing it right. Show us the actual code you are trying
to compile.

Here are some sample C programs that use complex numbers from the standard.
If your compiler does not compile it, then you do not have a working C99
compiler.

From ISO/IEC 9899:1999 (E) ©ISO/IEC:

#include <math.h>
#include <complex.h>
/* Multiplyz * w... */
double complex _Cmultd(double complex z, double complex w)
{
#pragma STDC FP_CONTRACT OFF
double a,
b,
c,
d,
ac,
bd,
ad,
bc,
x,
y;
a = creal(z);
b = cimag(z)
c = creal(w);
d = cimag(w);
ac = a * c;
bd = b * d;
ad = a * d;
bc = b * c;
x = ac - bd;
y = ad + bc;
if (isnan(x) && isnan(y)) {
/* Recover infinities that computed as NaN+iNaN ... */
int recalc = 0;
if (isinf(a) || isinf(b)) { // z is infinite
/* "Box" the infinity and change NaNs in the other factor to 0
*/
a = copysign(isinf(a) ? 1.0 : 0.0, a);
b = copysign(isinf(b) ? 1.0 : 0.0, b);
if (isnan(c))
c = copysign(0.0, c);
if (isnan(d))
d = copysign(0.0, d);
recalc = 1;
}
if (isinf(c) || isinf(d)) { // w is infinite
/* "Box" the infinity and change NaNs in the other factor to 0
*/
c = copysign(isinf(c) ? 1.0 : 0.0, c);
d = copysign(isinf(d) ? 1.0 : 0.0, d);
if (isnan(a))
a = copysign(0.0, a);
if (isnan(b))
b = copysign(0.0, b);
recalc = 1;
}
if (!recalc && (isinf(ac) || isinf(bd) ||
isinf(ad) || isinf(bc))) {
/* Recover infinities from overflow by changing NaNs to 0 ... */
if (isnan(a))
a = copysign(0.0, a);
if (isnan(b))
b = copysign(0.0, b);
if (isnan(c))
c = copysign(0.0, c);
if (isnan(d))
d = copysign(0.0, d);
recalc = 1;
}
if (recalc) {
x = INFINITY * (a * c - b * d);
y = INFINITY * (a * d + b * c);
}
}
return x + I * y;
}
/*
7 This implementation achieves the required treatment of infinities at
the cost of only one isnan test in ordinary (finite) cases. It is less than
ideal in that undue overflow and underflow may occur.
468 IEC60559-compatible complexarithmetic §G.5.1
©ISO/IEC ISO/IEC 9899:1999 (E)
8 EXAMPLE 2 Division of two double _Complex operands could be implemented
as follows.
*/
#include <math.h>
#include <complex.h>
/* Dividez / w ... */
double complex _Cdivd(double complex z, double complex w)
{
#pragma STDC FP_CONTRACT OFF
double a,
b,
c,
d,
logbw,
denom,
x,
y;
int ilogbw = 0;
a = creal(z);
b = cimag(z);
c = creal(w);
d = cimag(w);
logbw = logb(fmax(fabs(c), fabs(d)));
if (isfinite(logbw)) {
ilogbw = (int) logbw;
c = scalbn(c, -ilogbw);
d = scalbn(d, -ilogbw);
}
denom = c * c + d * d;
x = scalbn((a * c + b * d) / denom, -ilogbw);
y = scalbn((b * c - a * d) / denom, -ilogbw);
/* Recover infinities and zeros that computed as NaN+iNaN; */
/* the only cases are non-zero/zero, infinite/finite, and finite/infinite,
... */
if (isnan(x) && isnan(y)) {
if ((denom == 0.0) &&
(!isnan(a) || !isnan(b))) {
x = copysign(INFINITY, c) * a;
y = copysign(INFINITY, c) * b;
} else if ((isinf(a) || isinf(b)) &&
isfinite(c) && isfinite(d)) {
a = copysign(isinf(a) ? 1.0 : 0.0, a);
b = copysign(isinf(b) ? 1.0 : 0.0, b);
x = INFINITY * (a * c + b * d);
y = INFINITY * (b * c - a * d);
} else if (isinf(logbw) &&
isfinite(a) && isfinite(b)) {
c = copysign(isinf(c) ? 1.0 : 0.0, c);
d = copysign(isinf(d) ? 1.0 : 0.0, d);
x = 0.0 * (a * c + b * d);
y = 0.0 * (b * c - a * d);
}
}
return x + I * y;
}
/*
9 Scaling the denominator alleviates the main overflow and underflow
problem, which is more serious than for multiplication. In the spirit of the
multiplication example above, this code does not defend against overflow
and underflow in the calculation of the numerator. Scaling with the scalbn
function, instead of with division, provides better roundoff
characteristics.
§G.5.1 IEC60559-compatible complex arithmetic 469
*/

** Posted from http://www.teranews.com **

[Keith Thompson]

void main <nos...@nospam.invalid> writes:
> I'm rather new to complex numbers in C and was wondering, how do I
> initialize a complex variable properly if the imaginary part is 0.

[valid code snipped]

> What am I doing wrong?

You are complaining in comp.lang.c rather than submitting a bug report
to your compiler provider. And you are doing so quite deliberately.

You are a troll. Go away.

--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[lawrenc...@siemens.com]

Dann Corbit <dco...@connx.com> wrote:
>
> According to a sample in the C99 standard:
> 24 EXAMPLE 1 Provided that <complex.h> has been #included, the declarations
> int i = 3.5;
> complex c = 5 + 3 * I;

Note that that example is defective: "complex" is not a valid type
specifier on its own, it should be "float complex", "double complex", or
"long double complex" instead.
--
Larry Jones

I don't like these stories with morals. -- Calvin

[jacob navia]

lawrenc...@siemens.com wrote:
> Dann Corbit <dco...@connx.com> wrote:
>> According to a sample in the C99 standard:
>> 24 EXAMPLE 1 Provided that <complex.h> has been #included, the declarations
>> int i = 3.5;
>> complex c = 5 + 3 * I;
>
> Note that that example is defective: "complex" is not a valid type
> specifier on its own, it should be "float complex", "double complex", or
> "long double complex" instead.

I thought that this defect was removed in later editions.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Keith Thompson]

jacob navia <ja...@nospam.com> writes:
> lawrenc...@siemens.com wrote:
>> Dann Corbit <dco...@connx.com> wrote:
>>> According to a sample in the C99 standard:
>>> 24 EXAMPLE 1 Provided that <complex.h> has been #included, the declarations
>>> int i = 3.5;
>>> complex c = 5 + 3 * I;
>> Note that that example is defective: "complex" is not a valid type
>> specifier on its own, it should be "float complex", "double complex", or
>> "long double complex" instead.
>
> I thought that this defect was removed in later editions.

It was. The error was noted in DR #293
<http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_293.htm> and
corrected in TC3, which was incorporated into
<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf>.

[void main]

Keith Thompson wrote:

> void main <nos...@nospam.invalid> writes:
> > I'm rather new to complex numbers in C and was wondering, how do I
> > initialize a complex variable properly if the imaginary part is 0.
>
> [valid code snipped]
>
> > What am I doing wrong?
>
> You are complaining in comp.lang.c rather than submitting a bug report
> to your compiler provider. And you are doing so quite deliberately.

I wasn't complaining about anything. If this is a private group and
outsiders are not welcome here, you could have just said so without
the baseless accusations.

Instead, in my first post here I was told the issue does not show up
in MSVC, so it must be a troll? The world is not MSVC.

This thread's a troll because I'm posting here deliberately??

> You are a troll. Go away.

Thanks, I will.

I asked the same question someplace else and got a helpful response.

For the benefit of those who run into the same issue, here's the
deal: Some compilers can not handle initialization of complex numbers
at global level. Moving those variables to local level or doing initial
assignment to globals in code both work even with the imaginary part
being zero or left out.

Minor inconvenience, but I think I can live with that.

[Keith Thompson]

void main <nos...@nospam.invalid> writes:
> Keith Thompson wrote:
>> void main <nos...@nospam.invalid> writes:
>> > I'm rather new to complex numbers in C and was wondering, how do I
>> > initialize a complex variable properly if the imaginary part is 0.
>>
>> [valid code snipped]
>>
>> > What am I doing wrong?
>>
>> You are complaining in comp.lang.c rather than submitting a bug report
>> to your compiler provider. And you are doing so quite deliberately.
>
> I wasn't complaining about anything. If this is a private group and
> outsiders are not welcome here, you could have just said so without
> the baseless accusations.

No, it's not a private group.

It's possible that I was mistaken in my accusation. Let me explain
the background; perhaps you can clarify this.

lcc-win is a C compiler maintained by jacob navia (yes, he spells his
name in lower case), who posts here regularly. jacob has been
involved in a number of heated discussions here, some of them
involving his perceived attitude towards bug reports.

Several times, we've seem someone anonymously post a seemingly
innocent question here about whether some unnamed compiler's behavior
is correct. The thing is, the posted code appeared to be specifically
designed to trigger a specific bug in lcc-win that we had just
recently discussed. The post did not mention lcc-win by name or
mention the recent discussion.

My suspicion, and I think that of some of the other regulars, is that
such posts are specifically designed to provoke a strong reaction from
jacob navia, triggering yet another heated discussion -- something
this newsgroup definitely doesn't need.

Your post at the top of this thread seemed to fit that pattern. If
that was a coincidence, and your question was sincere, then I
apologize. (I'm not comfortable with conditional apologies, but I'm
still not certain what's going on here.)

For future reference:

If a compiler responds to a valid or invalid source file by crashing,
such as the message you quoted in your original message:

Error c:\tests\clc\ctest.c 3 Compiler error (trap). Stopping compilation

that's definitely a bug in the compiler, and it should be reported to
the compiler vendor.

If you're asking whether a compiler is behaving correctly (in your
case, it wasn't), it can be helpful to identify the compiler.

[Jack Pot]

lawrenc...@siemens.com wrote:

> Dann Corbit <dco...@connx.com> wrote:
>>
>> According to a sample in the C99 standard:
>> 24 EXAMPLE 1 Provided that <complex.h> has been #included, the
>> declarations int i = 3.5;
>> complex c = 5 + 3 * I;
>
> Note that that example is defective: "complex" is not a valid type
> specifier on its own, it should be "float complex", "double complex", or
> "long double complex" instead.

FWIW, lcc-win also accepts "void complex", which may seem somewhat less
portable, but using it in code does look very sophisticated!

[Flash Gordon]

Jack Pot wrote, On 16/08/08 00:21:

It probably reduces the portability as well since I doubt that "void
complex" is not one of the complex types specified by the standard.

Jacob, if lcc-win accepts "void complex" I think you should add it to
your bug list. This does *not* mean that you should fix it immediately,
it is up to you how you prioritise bug fixes and if/when you fix them.
--
Flash Gordon