Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!seismo!mimsy!eneevax!umd5!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.UUCP
Newsgroups: comp.lang.c
Subject: Re: Complex type ?
Message-ID: <5843@brl-smoke.ARPA>
Date: Fri, 8-May-87 02:21:06 EDT
Article-I.D.: brl-smok.5843
Posted: Fri May  8 02:21:06 1987
Date-Received: Sat, 9-May-87 08:47:59 EDT
References: <7264@brl-adm.ARPA> <734@sdchema.sdchem.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 39

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.