complex arithmetic in C99

[David Marsh]

Can someone show me or point me to an example of declaring and
initializing complex numbers in C99? Also, in looking at
complex.h, I don't see any library calls for + - * or /. How are
the basic arithmetic operations carried out?

David Marsh

 

[jacob navia]

Can someone show me or point me to an example of declaring and
initializing complex numbers in C99? Also, in looking at complex.h, I
don't see any library calls for + - * or /. How are the basic arithmetic
operations carried out?

David Marsh

#include <complex.h>
int main(void)
{
complex c = 1.2+0.67*I;
}

This defines the complex number 1.2+0.67i.

 

[user923005]

Can someone show me or point me to an example of declaring and
initializing complex numbers in C99? Also, in looking at
complex.h, I don't see any library calls for + - * or /. How are
the basic arithmetic operations carried out?

David Marsh

ISO/IEC 9899:1999 (E) ©ISO/IEC
page 128 Language §6.7.8
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.

 

[Lane Straatman]

#include <complex.h>
int main(void)
{
complex c = 1.2+0.67*I;
}

This defines the complex number 1.2+0.67i.

Are float _Complex , double _Complex and long double _Complex valid ISO C
types? LS

 

[Guest]

Are float _Complex , double _Complex and long double _Complex valid ISO C
types?

Yes. When complex.h is included, complex is nothing more than a macro
which expands to _Complex.

And _Complex by itself is not a valid type. The code as is shouldn't
compile without problems. It should read

#include <complex.h>
int main(void)
{
complex double c = 1.2+0.67*I;
}

The location of the double keyword is not important -- it may be before
or after complex -- but you can't omit it unless you choose to rely on
some compiler extension.

 

[jacob navia]

Harald van Dijk a écrit :

Yes. When complex.h is included, complex is nothing more than a macro
which expands to _Complex.

And _Complex by itself is not a valid type. The code as is shouldn't
compile without problems. It should read

#include <complex.h>
int main(void)
{
complex double c = 1.2+0.67*I;
}

The location of the double keyword is not important -- it may be before
or after complex -- but you can't omit it unless you choose to rely on
some compiler extension.

Thez C standard 6.7.8 "Initialization":
< quote >
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.
< quote >

Page 128

 

[Guest]

Harald van Dijk a écrit :

Thez C standard 6.7.8 "Initialization":
< quote >
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.
< quote >

The example is non-normative and wrong, and there is an open DR about
it (#293). The relevant constraint it violates is 6.7.2p2.

 

[jacob navia]

Harald van Dijk a écrit :

The example is non-normative and wrong, and there is an open DR about
it (#293). The relevant constraint it violates is 6.7.2p2.

Damm!!!

Because of that example,I had:
typedef long double _Complex complex;
in my complex.h!

 

[Keith Thompson]

jacob navia wrote: [...]

Thez C standard 6.7.8 "Initialization":
< quote >
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.
< quote >

The example is non-normative and wrong, and there is an open DR about
it (#293). The relevant constraint it violates is 6.7.2p2.

And the example is corrected ("complex" --> "double complex") in
n1124.

 

[Richard Heathfield]

jacob navia said:

Harald van D?k a écrit :

Damm!!!

Because of that example,I had:
typedef long double _Complex complex;
in my complex.h!

I doubt whether many here will be surprised to learn that there is yet
another bug in lcc-win32. It seems that its users may be able to give the
old excuse, "it must be a bug in the compiler", a new lease of life.

It needn't be that way, you know.

 

[jacob navia]

Richard Heathfield a écrit :

jacob navia said:




I doubt whether many here will be surprised to learn that there is yet
another bug in lcc-win32. It seems that its users may be able to give the
old excuse, "it must be a bug in the compiler", a new lease of life.

It needn't be that way, you know.

Pathetic. I have a bug in my compiler because THERE IS A BUG IN THE
STANDARD, and obviously it is MY FAULT heathfield...

Yes, It needn't be that way, you know. They should publish standards
without bugs. But since they are just humans, like me, they do make
bugs and wrote a bug in their example. Unaware of that I followed that
example, that I considered normative.

Of course beings like you never make any mistake.

Never

 

[Richard Heathfield]

jacob navia said:

Richard Heathfield a écrit :

Pathetic. I have a bug in my compiler because THERE IS A BUG IN THE
STANDARD, and obviously it is MY FAULT heathfield...

In this case, it isn't a normative part of the Standard, so yes, it's your
fault for trusting an example.

Yes, It needn't be that way, you know. They should publish standards
without bugs. But since they are just humans, like me, they do make
bugs and wrote a bug in their example. Unaware of that I followed that
example, that I considered normative.

That was your mistake and your fault. See Note 6 of the Foreword, which says
in part:

"In accordance with Part 3 of the ISO/IEC Directives, this foreword, the
introduction, notes, footnotes, and examples are also for information
only."

Of course beings like you never make any mistake.

You are mistaken. Again.

 

[Keith Thompson]

Harald van Dijk a écrit :

Damm!!!

Because of that example,I had:
typedef long double _Complex complex;
in my complex.h!

You might have better luck if you use n1124 as a reference rather than
the C99 standard itself. All changes are marked with change bars, so
you can easily see the differences.

 

[Lane Straatman]

:

You might have better luck if you use n1124 as a reference rather than
the C99 standard itself. All changes are marked with change bars, so
you can easily see the differences.

I came back to this older thread to see if I could confirm my suspicion that
_Complex were a keyword in the C99. I see no change bars here. I wonder if
_Complex came to the language earlier than did _Bool .
http://www.billfordx.net/screendumps/n1142_shot1.htm

Are the keywords that have been added to C99 mostly of the form _Something ?
I sure wish that electronic versions of the standard weren't a king's
ransom. LS

 

[Keith Thompson]

:

I came back to this older thread to see if I could confirm my suspicion that
_Complex were a keyword in the C99. I see no change bars here. I wonder if
_Complex came to the language earlier than did _Bool .
http://www.billfordx.net/screendumps/n1142_shot1.htm

Are the keywords that have been added to C99 mostly of the form _Something ?
I sure wish that electronic versions of the standard weren't a king's
ransom. LS

I paid $18 for my copy of the C99 standard in PDF format.

There are no changes in keywords between C99 and n1124. The new
keywords in C99 (relative to C90) are:

_Bool
_Complex
_Imaginary
inline
restrict

The committee *could* have spelled the last two as _Inline and
_Restrict, and perhaps added "inline" and "restrict" macros in some
new standard header, but they chose not to. I think they decided that
breaking existing code that uses "bool", "complex", or "imaginary" as
identifiers would have caused too many problems, but "inline" was
probably mostly used for compiler extensions very similar to the new
C99 feature, and "restrict" probably wasn't used as an identifier very
often.