Path: utzoo!dptcdc!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!pasteur!ames!hc!lanl!jlg
From: jlg@lanl.gov (Jim Giles)
Newsgroups: comp.lang.c
Subject: Re: fortran to C converter
Message-ID: <12247@lanl.gov>
Date: 18 Apr 89 20:13:09 GMT
References: <10176@socslgw.csl.sony.JUNET>
Organization: Los Alamos National Laboratory
Lines: 62

From article <10176@socslgw.csl.sony.JUNET>, by diamond@diamond.csl.sony.junet (Norman Diamond):
> [...]
> Perhaps the idiotic question should come first.  Why are two doubles a
> bad choice?  [...]

Two doubles are a bad choice because it's inefficient to do it that way.
On the Cray, doubles have 28 digits of precision, but it takes 50 (that's
right - FIFTY) time as long to compute with doubles as with singles.  That
doesn't even include the fact that doubles don't vectorize!  Single precision
carries 14 digits of precision and is adequate for most computation.  The
use of double should be for very rare cases in which single precision isn't
sufficient.

> [...]
>>      Class ordinary_number:: (integer, float)
>>
>>      Commutative infix operator '*' is
>>         Inline complex function mixed_mult (complex::x, ordinary_number::y)
>>            mixed_mult.real = x.real * y
>>            mixed_mult.imag = x.imag[* y   !To fix previous error]
>>         end
> 
> Looks Ada-like to me.  I only see one line there that a Fortran compiler
> would be happy with.  [...]

Look at the Fortran 8x document.  This syntax is similar to that in
the proposed standard (the differences are deliberate).

>          [...]    Anyway, here's what's wrong with folding too many
> declarations into one, with this kind of syntax:
> 
> Multiplication of complexes is commutative, but multiplication of
> matrices is not.  [...]

SO WHAT!  The declaration above doesn't even mention matrices.  Since
the whole idea of operator overloading is to provide for different
definitions of the operators for different argument types, I can define
multiplication on matrices (if I define such a type) later.

Anyway, the operator as declared here, is already perfectly acceptable
as an element-wise array operator (just like the other scalar operators
are).  Complex is, of course, a _scalar_ data type (as far as the
programming language is concerned).

>           [...] Multiplication of complexes and multiplication of
> matrices are both associative (which you forgot to mention).

I deliberately left the ASSOCIATIVE attribute out since I didn't want
to clutter the example.  Anyway, the associative attribute is only
useful if the compiler (or preprocessor) is capable of using it to
optimize expressions involving user-overloaded operators - something
C++ cannot do yet either.

> Addition of complexes is commutative but addition of strings is not.
> (Addition of strings, a popular feature in recent languages, should
> have been multiplication instead, but that would be Not Invented Here.)

Again, this doesn't have anything to do with the example given.  As for
the NIH syndrome (Not Invented Here), I can only say that it can be
correctly applied as a derogatory phrase if (and only if) the proposed
functionality is already readily available elsewhere.  It isn't in this
case.