Problematic complex notation in C99

[jacob navia]

Background:

The C99 committee decided NOT to use existing practice and defined a new
notation for complex numbers:

Instead of

double complex foo = 1.2+2.3i;

that is used in gcc

the standard decided to introduce a NEW notation:

double complex foo = 1.2+2.3*I;
-----------------------------------------------------------------

The standard says in 7.3.1.3
The macro
I
expands to either _Imaginary_I or _Complex_I.

OK

It says too:

The macro _Complex_I expands to a constant expression of type const
float _Complex, with the value of the imaginary unit.

OK

Now, there is a small problem...

How do I define the imaginary unit?

I can't say

float _Complex _Complex_I = 0.0f + 1.0f*I;

as it would recurse!

THEN

The header complex.h MUST use non-standard notation to define
_Complex_I.

Obviously the solution is to write:

float _Complex _Complex_I = 1.0i;

(as gcc does in their header file complex.h)


I still do not understand why the committee decided not to use existing
practice of adding an 'i' suffix to the complex numbers and decided to
create a new notation full of problems:

(1) This notation depends on a header file complex.h to be able to
recognize a complex constant. If you do not include the header
file the literal complex constants wont be recognized.

(2) If the user redefines the macro "I", complex numbers can't be parsed
anymore. Note that the standard explicitly allows for redefinition
of "I". Go figure.

(3) All header files "complex.h" *must* use NON STANDARD notation to
define the _Complex_I variable.

(4) All programs that define complex constants are assuming that the
_Complex_I variable doesn't change to be able to simplify the

expression
double complex foo = 2.3+5.8*I;

If a compiler simplifies this to a single complex number calculated at
compile time it is assuming that the value of _Complex_I doesn't change.
If we put _Complex_I as
#define _Complex_I (1.0i)

that will work but then we are expanding non-standard notation all over!

Since the standard implicitly assumes the I suffix notation then:

WHY DO WE HAVE TO DO ALL THIS CONTORTIONS?

Why can't we write

double complex foo = 1.2+2.3i;

and be done with it???

That would obviate the need to define the macro "I" and to have
_Complex_I and all that absurd machinery.

Why make it more complicated? Can't we simplify this and use
the suffix notation?

 

[Keith Thompson]

Background:

The C99 committee decided NOT to use existing practice and defined a new
notation for complex numbers:

Instead of

double complex foo = 1.2+2.3i;

that is used in gcc

the standard decided to introduce a NEW notation:

double complex foo = 1.2+2.3*I;

[...]

You already posted this to comp.std.c. Why post it separately to
comp.lang.c?

 

[CBFalconer]

Background: The C99 committee decided NOT to use existing
practice and defined a new notation for complex numbers:

Instead of
double complex foo = 1.2+2.3i;
that is used in gcc the standard decided to introduce a NEW
notation:
double complex foo = 1.2+2.3*I;

By the 100 odd lines of complaint I deduce that lcc-win32 still
does not implement the C99 specification. Why not list the known
incomplete areas, rather than having all your users guess?

 

[James Dow Allen]

Instead of
double complex foo = 1.2+2.3i;

I'm not a complex guy but this sure seems like the way to do it.
" 2.3i " is otherwise illegal, right?

that is used in gcc
the standard decided to introduce a NEW notation:
double complex foo = 1.2+2.3*I;

The standard says in 7.3.1.3
The macro
I
expands to either _Imaginary_I or _Complex_I.

I is a macro?? Do I misunderstand? We may not condone
people who've used I as a global variable (or their own
macro), but do we need to persecute them?

I've been stung -- and hence annoyed -- by the preemption
of j0, j1, etc. in <math.h> Would bessel_j0() have been
too burdensome?? After all, lazy typists can always define
their own macros for abbreviation.

(One could argue 'j0' (or 'I') is too short to be a good identifier,
but doesn't this cut the other way as well?)

<begin flame-bait>
I know little or nothing about C standardization,
but noticed that single-vendor but public *hardware*
standards (e.g. CDC's SMD, Motorola's VMEBus), were often
much admired and copied, while Committee standards
(e.g. IPI) were often over-complex, problematic
and unpopular. Is the case of the "single-vendor" gcc
vs Committee Standard C similar?
<end flame-bait>

James Dow Allen

 

[jacob navia]

By the 100 odd lines of complaint I deduce that lcc-win32 still
does not implement the C99 specification.

This is not true. Complex numbers are implemented since at least 4 years
now.

I am reimplementing them using SSE3.


Why not list the known

incomplete areas, rather than having all your users guess?

Why not shut up before' spreading misinformation?

 

[James Kuyper]

jacob navia <[email protected]> might have writ, in [email protected]: ....

I is a macro?? Do I misunderstand? We may not condone
people who've used I as a global variable (or their own
macro), but do we need to persecute them?

All they need to do to keep their code working the way it always has is
avoid #include <complex.h> (directly or indirectly) in any translation
unit where I is used in some conflicting fashion. This is an
inconvenience, but given the limited popularity of complex math, not an
major one. I don't think this rises to the level of "persecution".

 

[Eric Sosman]

[...]
I've been stung -- and hence annoyed -- by the preemption
of j0, j1, etc. in <math.h> Would bessel_j0() have been
too burdensome?? After all, lazy typists can always define
their own macros for abbreviation.

Were j0() and j1() added in a TC or something? I can't
find them in ISO/IEC 9899, so if they appear in your system's
<math.h> it's apparently not the Standard's fault.

 

[Bart]

Background:

Instead of

double complex foo = 1.2+2.3i;

that is used in gcc

the standard decided to introduce a NEW notation:

double complex foo = 1.2+2.3*I;

Why make it more complicated? Can't we simplify this and use
the suffix notation?

The suffix works well for constants: 1.0+2.0i. For named values, it's
not so good:

a + b i

The new notation a + b*I works better in this case.

As to the value of I, how about:

#define I sqrt(-1)

?

 

[Ben Bacarisse]

I've been stung -- and hence annoyed -- by the preemption
of j0, j1, etc. in <math.h> Would bessel_j0() have been
too burdensome?? After all, lazy typists can always define
their own macros for abbreviation.

(One could argue 'j0' (or 'I') is too short to be a good identifier,
but doesn't this cut the other way as well?)

I think the target of your ire should be POSIX not C.

 

[Mark Wooding]

Were j0() and j1() added in a TC or something?

They're in POSIX.1-2001.

-- [mdw]

 

[Ben Bacarisse]

As to the value of I, how about:

#define I sqrt(-1)

?

The definition must be usable in static initialisers and function
calls are not.

 

[Nate Eldredge]

That's a very good point. And you need the space, as otherwise its
parsed as a variable "bi", rather than two variables.

Maybe the gcc model disallows non-constant multipliers?

Yes, the "2.0i" syntax in gcc is only for constants. For non-constants,
you would presumably do `a + b * 1.0i'.

 

[jacob navia]

All they need to do to keep their code working the way it always has is
avoid #include <complex.h> (directly or indirectly) in any translation
unit where I is used in some conflicting fashion. This is an
inconvenience, but given the limited popularity of complex math, not an
major one. I don't think this rises to the level of "persecution".

Well, if you use any literal constant of complex type you can't avoid
including complex.h. See the message that started this conversation

 

[James Kuyper]

Bart wrote:
....

As to the value of I, how about:

#define I sqrt(-1)

sqrt(-1) is a domain error. ITYM csqrt(-1)? Still not a good idea, as
Ben has pointed out; but at least it would have the right value.

 

[CBFalconer]

CBFalconer wrote:

.... snip about lcc-win and C99 ...

Why not shut up before' spreading misinformation?

If it is misinformation you haven't corrected it. Where is the
complete list of things unimplemented?

 

[CBFalconer]

All they need to do to keep their code working the way it always
has is avoid #include <complex.h> (directly or indirectly) in
any translation unit where I is used in some conflicting fashion.
This is an inconvenience, but given the limited popularity of
complex math, not an major one. I don't think this rises to the
level of "persecution".

Anything with which Jacob fails to completely agree is due to the
concentrated persecution of him by c.l.c regulars. They
communicate by ESP to ensure that any requirements cause the
maximum problems for Jacob.

 

[CBFalconer]

They're in POSIX.1-2001.

Er - POSIX is not the C standard. See C99 below.

Some useful references about C:
<http://www.ungerhu.com/jxh/clc.welcome.txt>
<http://c-faq.com/> (C-faq)
<http://benpfaff.org/writings/clc/off-topic.html>
<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf> (C99)
<http://cbfalconer.home.att.net/download/n869_txt.bz2> (pre-C99)
<http://www.dinkumware.com/c99.aspx> (C-library}
<http://gcc.gnu.org/onlinedocs/> (GNU docs)
<http://clc-wiki.net/wiki/C_community:comp.lang.c:Introduction>
<http://clc-wiki.net/wiki/Introduction_to_comp.lang.c>

 

[Keith Thompson]

... snip about lcc-win and C99 ...

If it is misinformation you haven't corrected it. Where is the
complete list of things unimplemented?

Upthread, you wrote:
| By the 100 odd lines of complaint I deduce that lcc-win32 still
| does not implement the C99 specification. Why not list the known
| incomplete areas, rather than having all your users guess?

Your deduction is unfounded. The fact that jacob asked some legimate
questions about a C99 feature does not imply that his compiler fails
to conform.

On the other hand, it turns out that lcc-win32 does have some
conformance problems in the area of complex numbers, which I'll
report later in a more appropriate forum. (I have the version
from Feb 22; perhaps it's been corrected since then.)

 

[James Kuyper]

Anything with which Jacob fails to completely agree is due to the
concentrated persecution of him by c.l.c regulars. They
communicate by ESP to ensure that any requirements cause the
maximum problems for Jacob.

Note that it was James Dow Allen, not jacob, who introduced the idea
that it was "persecution". While misperceiving criticism as a personal
attack is one of jacob's flaws, this is not an example of that flaw.

 

[Richard Bos]

You already posted this to comp.std.c. Why post it separately to
comp.lang.c?

Because unlike you, most of comp.std.c chose _not_ to stroke jacob's ego
by rising to the bait.

Richard