Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-lcc!styx!ames!ucbcad!ucbvax!sdcsvax!sdchem!tps
From: tps@sdchem.UUCP (Tom Stockfisch)
Newsgroups: comp.lang.c
Subject: Re: Complex type ?
Message-ID: <734@sdchema.sdchem.UUCP>
Date: Thu, 7-May-87 17:55:36 EDT
Article-I.D.: sdchema.734
Posted: Thu May  7 17:55:36 1987
Date-Received: Sat, 9-May-87 09:52:56 EDT
References: <7264@brl-adm.ARPA>
Sender: news@sdchem.UUCP
Reply-To: tps@sdchemf.UUCP (Tom Stockfisch)
Organization: UC San Diego
Lines: 29

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