[comp.lang.c] Complex type ?

lyle@ads.arpa (05/06/87)

	C is an evolving language.  I will make a possibly sacrilegious
suggestion that the type "complex" be incorporated.  After all, such a
type is now a part of LISP (Common).

	The purest says:" Well, one can just define a structure complex."

	(Many years ago I was discussing with a friend the relative
utility of FORTRAN and ALGOL for numerical work.  I mentioned that
ALGOL did not have a type COMPLEX.  He said, "Well you can just write
a little procedure.")

	However, the resultant code form using structures and func-
tions is much less readable and harder to check.  (I have enough
trouble with "pow (x,y)" compared with x**y.)

...

struct complex
{
double re;
double im;
};


{
...

struct complex complex_mult();

struct complex A, B, C;
struct complex P;

P = complex_mult(A, complex_mult(B, C));

...

}

	One could use a shorter form, such as "cm()" instead of
"complex_mult()", but that doesn't really get to the point.

P = A * B * C;

is more easily read and checked.

(I am new to "info-c; perhaps this topic has come up before.)

edw@ius2.cs.cmu.edu (Eddie Wyatt) (05/07/87)

In article <7264@brl-adm.ARPA>, lyle@ads.arpa (Lyle Bacon) writes:
> 
> 	C is an evolving language.  I will make a possibly sacrilegious
> suggestion that the type "complex" be incorporated.  After all, such a
> type is now a part of LISP (Common).
> 
> 	The purest says:" Well, one can just define a structure complex."
> 
> 	(Many years ago I was discussing with a friend the relative
> utility of FORTRAN and ALGOL for numerical work.  I mentioned that
> ALGOL did not have a type COMPLEX.  He said, "Well you can just write
> a little procedure.")
> 
> 	However, the resultant code form using structures and func-
> tions is much less readable and harder to check.  (I have enough
> trouble with "pow (x,y)" compared with x**y.)
> 
> ...
> 
> struct complex
> {
> double re;
> double im;
> };
> 
> 
> {
> ...
> 
> struct complex complex_mult();
> 
> struct complex A, B, C;
> struct complex P;
> 
> P = complex_mult(A, complex_mult(B, C));
> 
> ...
> 
> }
> 
> 	One could use a shorter form, such as "cm()" instead of
> "complex_mult()", but that doesn't really get to the point.
> 
> P = A * B * C;
> 
> is more easily read and checked.
> 
> (I am new to "info-c; perhaps this topic has come up before.)


    Sounds like you should be programming in ADA or some other data abstract
language.  If you want to add a new type to the language, just make a package
for it and defined the operators on it.  I do believe that you are allowed to
define *+-... over other data types and still use the infix notation 
(don't take my word for it through, I'm not a ADA hacker).

  One problem with adding a new data type (or any new feature) to any
language is, one must determine how the new feature could interact with
existing features and defined the semantics of this new feature with respects
to every other feature. Example with the complex type:

    int x;
    complex y,z;

    y = x + z;

Is it legal? 
-- 
					Eddie Wyatt

e-mail: edw@ius2.cs.cmu.edu

gwyn@brl-smoke.ARPA (Doug Gwyn ) (05/07/87)

Complex numbers, in-line functions, and several other possibly
worthy extensions to C have indeed been discussed before and
considered by X3J11 for the Draft Proposed Standard.  Most of
these extensions were NOT put in the standard, out of a desire
to keep the language and its implementation relatively small.
(Complex numbers are often requested by Fortran folk; at the
last X3J11 meeting a nice proposal (by Tom ? of Cray? -- my
notes aren't at hand) for them was defeated; as I recall, it
actually gathered a simple majority, but since the Draft went
out for public review it now takes a 2/3 majority to make
substantive changes.)  Since several vendors feel the
necessity to supply some of these extensions for their
customers, it would be nice if implementors would agree on the
syntax and semantics of such extensions.  To this end, Rex
Jaeschke (of the C Journal) organized a BOF session at the
last X3J11 meeting.  We drew up a list of proposed extensions
(I forget how many, but I think over 30) and took a poll to
determine interest in each one.  For those extensions having
the most interest, "points of contact" were established; their
voluntary r^ole is to co"ordinate interested parties and
mediate ensuing discussions.  The idea is to try to develop
consensus for the form of the extensions, to "publish" to
other interested parties results of experiments with them, and
generally to garner experience with the extensions.  It is
felt that any extension that has developed widespread vendor
and customer experience and support by the time of the NEXT C
standards committee (something like 5-10 years hence) will
stand an excellent chance of being incorporated into the
revised standard.

I don't have a list of all the extensions and POCs; I'm POC
for three topics (which I would have to look up, except I
remember that one of them was 0-sized data objects; so far
nobody who had said they were interested in my topics has
contacted me, probably because we're all too busy trying to
get the first standard out).  I think Rex was going to
publish the list in the C Journal.

While you're waiting for your compiler vendor to get together
with Tom or whoever the POC is and implement complex data
types, you'll have to use the struct & library-routine
approach for complex arithmetic.  I have an implementation
you can build on; I'll try to package it up for mod.sources.

gwyn@brl-smoke.ARPA (Doug Gwyn ) (05/07/87)

In article <1148@ius2.cs.cmu.edu> edw@ius2.cs.cmu.edu (Eddie Wyatt) writes:
>    int x;
>    complex y,z;
>    y = x + z;
>Is it legal? 

Certainly it would be.  A more interesting example is:
	x = z;
If I were designing the extension I'd make this one illegal.
(There would be "real part", "imaginary part", and "modulus"
operators, and you'd have to specify which one you mean.)

The point about each new feature interacting with the ones
that already exist is valid and important.

guy@gorodish.UUCP (05/07/87)

> 	C is an evolving language.  I will make a possibly sacrilegious
> suggestion that the type "complex" be incorporated.  After all, such a
> type is now a part of LISP (Common).

With any luck, by the time there is sufficient demand for a "complex"
data type in C, it will have been supplanted by C++.  You can add a
"complex" data type to C++ simply by using facilities in the language
including operator overloading.

karl@haddock.UUCP (Karl Heuer) (05/07/87)

In article <1148@ius2.cs.cmu.edu> edw@ius2.cs.cmu.edu (Eddie Wyatt) writes:
|In article <7264@brl-adm.ARPA>, lyle@ads.arpa (Lyle Bacon) writes:
|>C is an evolving language.  I will make a possibly sacrilegious suggestion
|>that the type "complex" be incorporated.  After all, such a type is now a
|>part of LISP (Common).  [Using a struct complex is inelegant because] the
|>resultant code form using structures and functions is much less readable and
|>harder to check.
|
|Sounds like you should be programming in ADA or some other data abstract
|language.

I would recommend C++.  It's almost entirely upward compatible with C, and
allows you to assign operator semantics for new types.  This has already been
done for "complex", so you can write "z = z1 * z2 * z3" which seems to be what
you want.  (Also, this will generate inline code, not a function call.)

Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint

ark@alice.UUCP (05/07/87)

In article <7264@brl-adm.ARPA>, lyle@ads.arpa (Lyle Bacon) writes:
> 
> 	C is an evolving language.  I will make a possibly sacrilegious
> suggestion that the type "complex" be incorporated.  After all, such a
> type is now a part of LISP (Common).

I suggest you switch to C++, in which it is easy to define
a complex type if you want one.

tps@sdchem.UUCP (Tom Stockfisch) (05/08/87)

In article <7264@brl-adm.ARPA> lyle@ads.arpa (Lyle Bacon) writes:

>	C is an evolving language.  I will make a possibly sacrilegious
>suggestion that the type "complex" be incorporated.
>	The purest says:" Well, one can just define a structure complex."
>	...However, the resultant code form using structures and func-
>tions is much less readable and harder to check....
>P = complex_mult(A, complex_mult(B, C));
>
>P = A * B * C;
>is more easily read and checked.


This only solves the problem for the type "complex".  What about vectors
and matrices and (use your imagination)?  What C really needs is the
operator-overloading facility already available in C++.  With this you
can re-define + and * for any new data type you please.  Even if you
use this only for type complex, its still a gain because you can use
your favorite complex operation algorithms.

What we number-crunchers really need to do is convince the X3J11 committee
to borrow just this one more idea (I promise, this is the absolute last one,
but in my opinion the most important) from C++ and put it in the new
standard.



|| Tom Stockfisch, UCSD Chemistry	tps%chem@sdcsvax.ucsd.edu
					or  sdcsvax!sdchem!tps

gwyn@brl-smoke.UUCP (05/08/87)

In article <734@sdchema.sdchem.UUCP> tps@sdchemf.UUCP (Tom Stockfisch) writes:
>This only solves the problem for the type "complex".  What about vectors
>and matrices and (use your imagination)?  What C really needs is the
>operator-overloading facility already available in C++.  With this you
>can re-define + and * for any new data type you please.

This is similar to a point I often make when people ask for a new
data type.  There is a problem, though, with trying to borrow the
real-number arithmetic operations for use with other types of
"number".  For example, I am at a loss as to what U*V should mean
for U,V vectors.  Is that an outer product? wedge product? inner
product? what metric?  (Certainly the componentwise product of the
holors is not what is wanted.)  Multiplication of fancy numbers (e.g.
matrices) tends not to be commutative.  What symbol do we use for the
very important transposition operator?  How about inverses (division
is often not a useful concept for fancy numbers)..

Considerations such as these have convinced me that "operator
overloading" is much less useful than its advocates claim.

To implement many types of extended "numbers", one has to resort
to a different interface than for real-number arithmetic.  The
main reason complex numbers may be worth singling out for
favorable treatment is that they algebraically "complete" the real
number field.  (A much less important reason is that many
engineering applications in Fortran heavily rely on them; if one
is thinking of wooing Fortran programmers over to C -- the value
of which I find debatable -- then this issue keeps surfacing.)

Personally I would rather have good general set operations.
Several number-type extensions are topics identified by the BOF
I recently wrote about.  Those with strong advocates will
probably come to pass in some implementations of C.

X3J11, and our redactor in particular, is well aware of C++.  For
the most part there seems to be a consensus that it would be
premature to adopt much of C++ into C itself, although several C++
features with proven track records have made it into the Draft
Proposed Standard.

dc@sdd.UUCP (Daniel Corbett) (05/09/87)

	If you want to create your own types, use C++!  It includes
a complex library that one can do as follows:

	complex xx(3.5,4.0); /* declaration for complex variable xx
			      *	initialized to 3.5 + 4i
			      */

	complex yy = log(xx) + log(3.2);
			     /* This express ion involves a mixture
			      *	of real values: log(3.2) and complex
			      *	values log(xx) and the sum.
			      */


						-dc

edw@ius1.cs.cmu.edu (Eddie Wyatt) (05/10/87)

In article <734@sdchema.sdchem.UUCP>, tps@sdchem.UUCP (Tom Stockfisch) writes:
> This only solves the problem for the type "complex".  What about vectors
> and matrices and (use your imagination)?  What C really needs is the
> operator-overloading facility already available in C++.  With this you
> can re-define + and * for any new data type you please.  Even if you
> use this only for type complex, its still a gain because you can use
> your favorite complex operation algorithms.
> 
> What we number-crunchers really need to do is convince the X3J11 committee
> to borrow just this one more idea (I promise, this is the absolute last one,
> but in my opinion the most important) from C++ and put it in the new
> standard.
> 
> 
> 
> || Tom Stockfisch, UCSD Chemistry	tps%chem@sdcsvax.ucsd.edu
> 					or  sdcsvax!sdchem!tps

  No, what C really needs is not operator-overloading.  There already 
exist a class of languages that provide such facilities, use them instead.
What you're sugguesting is to change C into a data abstact language, which
is not the intended purpose.  If you want  a data abstract language that
looks like C use C++, just like you said. Listen here people, C is not
Fortrash, Pascal, Ada or Lisp, it is C, a simple procedural oriented language
that allows one to do some very powerful and sometimes unkosher things.

    I view the language as a modified form of assemble language.  It gives
you the high level control constructs of block structured languages, yet
allows you to get at some of the low level operations of the machine
such as the bit operations.  By the way, in the current project that
I am working on, if I had had a say in the language we are using, I would
have choosen a data abstract language, posibly C++.  I find it the case
that I need routines for queues and hash tables for many different
data objects.  I have written generic queue and hash table routines
but I have some very unkosher code in one place where I do take advantage
of sizeof(int) == sizeof(char *) on the machines that I work on. I should
sometime go back and change that.

  Anyway, back to the original topic of complex types.  If the complex number
is added to the language should the real and imaginary parts be represented
as doubles or singles.  Or should there be two types of complex numbers
long complex and the complex?  What are the semantics of complex++ and
complex--?  Also should any semantic meaning be given to complex1 < complex2?

  I personal have nothing against adding the complex type to the  language.  
But if it is added, I at least hope that all the language semantic issues are
WELL thought out before implimenting them.


						Eddie Wyatt

e-mail edw@ius2.cs.cmu.edu
-- 
					Eddie Wyatt

They say there are strangers, who threaten us
In our immigrants and infidels
They say there is strangeness, too dangerous
In our theatres and bookstore shelves
Those who know what's best for us-
Must rise and save us from ourselves

Quick to judge ... Quick to anger ... Slow to understand...
Ignorance and prejudice and fear [all] Walk hand in hand.
					- RUSH 

Richard_s_Stoneston@cup.portal.com (10/18/87)

Well, here's my two cents regarding the future use of type complex in C.
As you may know, C's advantage is its smallness, and porting versions of
the compiler around is easy enough to do because of this advantage. One reason
that Fortran has a complex type is that it is a mathematical language. (So is
APL= but it doesn't have complex) But, Fortran has NO structure definition in
the language, so it is even more necessary for it to provide this type.  C,
on the other hand, can define types very easily through typedef and struct
and enum.  All you have to do is define the code to handle the types.
You don't have to require that the complex definition, as an example, need to
be inside the parser.

ljz@fxgrp.UUCP (Lloyd Zusman) (10/19/87)

In article <1015@cup.portal.com> Richard_s_Stoneston@cup.portal.com writes:
>Well, here's my two cents regarding the future use of type complex in C.
> ...
>C, on the other hand, can define types very easily through typedef and struct
>and enum.
> ...
>You don't have to require that the complex definition, as an example, need to
>be inside the parser.

I agree.  But this question and many other questions of its ilk that come
up here can be answered as follows:

     You should try C++

Some of us tend to argue ad infinitum (and perhaps even ad nauseum) as
to which non-traditional C features can be added to C in some future
release.  C++ was developed (at least in part) to address some of
these issues.  For example, in C++, a new data type called "complex"
can be defined as, say, a structure consisting of two floats.  A
series of functions to operate on this 'complex' type can be defined,
and these can be mapped into existing C operators.  You can, for
example, define the operators "+", "-", "*", and "/" to call your
complex functions if any of the the operands have been defined as
complex.  This can be generalized to any new data type.

C++ has several other nice features such as inline functions (which
can be used to supplant #define macros in many cases),
call-by-reference (which in many cases eliminates the need to remember
whether to prepend a '&' to a parameter in function call and a '*'
when referring to the parameter within the function), variable
declaration anywhere in a block before it is referred to, data hiding,
and object-oriented constructs.  Some of people who want to add
features to C might find themselves quite satisfied with what already
exists in C++.

C++ is very similar to C and you will not lose very many existing C
features by using it.  The C++ bible is a book called "The C++
Programming Language" by Bjarne Stroustrup and published by
Addison-Welsey.  Why not check it out?


-- 

Lloyd Zusman
...!ames!fxgrp!ljz