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