🚀 go-pugleaf

In article <14255@lambda.UUCP> jlg@lambda.UUCP (Jim Giles) writes:
 > In article <8836@boring.cwi.nl>, dik@cwi.nl (Dik T. Winter) writes:
 > > In article <14251@lambda.UUCP> jlg@lambda.UUCP (Jim Giles) writes:
 > >  >            In fact, for programs of any really useful size, passing
 > >  > array arguments is vital.  In this respect, at least, C really _DOESN'T_
 > >  > have arrays.
 > >  > 
 > > But in this aspect Fortran (at least upto and including 77) does not have
 > > arrays either.  Let's compare some languages (for a matrix-vector product
 > > routine*):
Note (I will come back to that later) that it is about the support of arrays.
 > 
 > You are making two errors here.  The first is to misrepresent Fortran (see
 > below).
Perhaps; but I do not think so.
 >          The second is to assume that Fortran is a particular favorite of
 > mine.  Fortran has many faults.  Although none of them are quite as serious
 > as those of C, the language is in need of many improvements.
I never assumed anything, I just did a comparison.  And I really do not
know whether Fortran is inherently better than C.
 > 
 > Since you quoted my statement out of context (without even using elipses)
 > you missed an important part of what I said.
We are in the same boat I think.
 >                                               C converts arrays into 
 > pointers AND provides no way to undo the damage!! ** _SOME_ Fortran
 > environments (alright: most) do convert arrays to pointers - unaliased
 > pointers.  All fortran environments not only _allow_ you to redeclare
 > your arrays as such in the procedure - but require it!  Only the last
 > dimension of an array argument may be left unspecified.
C provides a way to undo the damage which is no more proof against abuse
as the Fortran way, again, see below.  And I know a lot of Fortran
environments that do allow you to redeclare your arrays in a procedure
as whatever you want.  I know this is against language rules, but ...
In fact there is no more and no less safety in C than in Fortran.  In C,
when an array is passed to a procedure, the procedure receives a pointer.
You can access through that pointer only elements of the original array;
everything else is against the standard (at least ANSI, and disregarding
the possibility to calculate the address just beyond the last element).
The guarantee of unaliased pointers in Fortran is fine, but is not the
essence of support for arrays.  There are languages that have fuller
support for arrays than Fortran and that disallow aliases (Ada) and
others that allow aliases (Algol 60).  Note that I hinted in my
original article on the possibilities for optimization when aliasing is
not allowed.
 > 
 >    **Note: Fortran is deliberately designed so that parameter passing
 > (including arrays) can be carried out as either call-by-reference or
 > as call-by-value/result.  So, in a distributed environment, copy-in/out
 > may actually be the _most_ efficient parameter passing mechanism and
 > Fortran is allowed to use it.  This dual implementation possibility is
 > why aliasing is prohibited in Fortran (at least, the original reason -
 > better optimization is a _real_ good reason to keep the prohibition).
Yup, the same applies to Ada.  But they made a clean breast.  And they
require call-by-value/result for scalars.
 > 
 > > [...]
 > > Fortran:
 > > 	      SUBROUTINE MATVEC(M, V, W, L1M, U1M, L2M, U2M)
 > > [...]
 > > 	C     NO BOUND CHECKING POSSIBLE
 > 
 > This is false.  I haven't ever worked with a Fortran environment which
 > didn't do array bounds checking (at least as an option).  Of course, the
 > compiler _does_ have to just take the caller's word for it that the array
 > bounds that he passed are correct.  In fact, the compiler has to take the
 > caller's word for it that the array really has as many dimensions as the
 > code claims.
But if the compiler has to assume things, it is clear no checking can be
performed!  So I stand by my claim, no bound checking is possible, except
for local accesses against the locally declared bounds of course, but that
is bogus.  I know, the routine is correct, but is it called correctly?
(ellipses for once)
 > ...
 > > C (Fortran style (you can write Fortran in any language!)):
 > ...
 > > 		/* No bound checking possible. */
 > 
 > Again false.  But this time, the bounds checking must be done 'by hand'.
Again it is clear that you think 'bounds checking' is only local; it is not.
 > ...
 >                                                          In C, you also
 > have to do all the subscripting 'by hand' - which involves, at least,
 > an extra macro definition for each array argument.
What is the difference with a DIMENSION statement?  I know the syntax is
a bit less clear; but effectively they are the same.
 >                                                     (Some C users claim
 > that using macros for this is inefficient and that you should always
 > do the subscript expressions explicitly - presumably because many C
 > compilers miss the strength reduction on the multiplies.
This is a bogus argument.  I know a Fortran compiler that is not able to
compile DSQRT correctly.  Do I avoid all occurrences of DSQRT?  No, I
yell at the supplier.  (At least, I would yell if it would be worth the
hassle, but considering the number of bugs in that compiler...)
 >                                                           I wonder if
 > Piercarlo Grandi ever uses cars or elevators or if his brand of do-it-
 > the-hard-way masochism is limited to programming only :-)
Let's avoid Piercarlo Grandi.
 >                                                            Finally,
 > there is no way in C to tell the compiler that your pointers (I mean
 > arrays) are not aliased - here is damage which simply can't be undone.
But that is of course a whole different can of worms.
 > ...
I agree on this.  (Oh, it is about RESHAPE and IDENTIFY and so on.)
 > ...
(About generating equivalent code.)
Again aliassing is a problem.  But the code I presented has no problems
with aliasses unless used on multi-processor systems (only innerproducts
are used, so vector processors have no problems, unless they are not good
at that, and some are).

Summarizing:  the support for arrays in C is only slightly worse than in
Fortran.  Problem areas are:
1.  Aliassing (as discussed ad nauseum).
2.  The pre-ANSI requirement to do everything in double precision, which no
    -f flag is able to annihilate (strange enough, not yet discussed in this
    thread).

Many C users think that aliassing can be detected by the run time, so that
multiple parts of code can be generated depending on the presence of an
alias or not.  This is not true.  If two pointers point to different
arrays one may not compere them.  If they point to identical arrays one
may compare, but there are (generally used) access methods where a complete
detection of the absense of aliassing takes as much time as the operation
itself.

Many Fortran users think that aliassing is allowed and hence do some
defensive programming against it (or even state in the documentation that
aliassing is allowed).  Also this is impossible.  Given that two parameters
are (against the rules) aliasses of each other, there is no way to detect
that.  A simple case I encountered was in a long integer package.  The
routine to subtract numbers 'SUB(A, B, C)' took two input arrays A and B
and one output array C.  An attempt was made to detect whether A and B
where the same.  The test failed on at least one system.

You may now ask: "what is your favorite language?"  I would answer that I
do not know.  I use the language available to perform the task that has to
be done.  All languages I used/use have their defects.  I think there is
nothing to be done about that; I am not in the field of Herman Rubin who
proposes a universal language encompassing all current and future hardware
instructions directly available.  I will do assembler without complaining
if need arises (or even if there is no need, but than just for fun).
But, for numerical processes, Pascal is inadequate, unless it is an
implementation with conformant arrays (Level 2?), Fortran and C are
semi-adequate.  Algol 68 is very nice, but not readily available
(Herman Rubin ought to learn it and get a compiler; he could get all
the infix operators he wants), and Algol 60 is pretty good of course.
And, need I mention Ada?  Yes, she has her good points, but of course
also her defects.
-- 
dik t. winter, cwi, amsterdam, nederland
dik@cwi.nl