kwh@bentley.UUCP (KW Heuer) (05/26/86)
In article <1594@ecsvax.UUCP> ecsvax!dgary (D Gary Grady) writes: >Right now Fortran has four things over C: Of which I'd like to address the first two. >o A richer set of floating point operators, including exponentiation and > the so-called "in-line" functions (many of which ARE in C). I think you mean "builtin" rather than "inline". I don't even consider that a significant difference, much less an advantage of FORTRAN. Exponentiation in general is syntactically neater in FORTRAN but semantically identical on most machines. Exponentiation with integer exponents is a problem in C; it isn't even available as a library function! When the exponent is constant (usually 2 or 3 in practice) it could easily be coded inline, but it's not clear whether that's sufficient justification for making it an operator. >o A way of passing different-sized multidimensional arrays to the same > subroutine. (For instance, right now it is not possible to write a > function in C that will invert a matrix of arbitrary size without use > of some "trick," like making the incoming matrix one-dimensional and > hard-coding the subscript computation or using arrays of pointers to > pointers.) Again, this is merely a syntactic quibble -- what FORTRAN does is equivalent to the one-dimensional "trick", but it's hidden from the user. FORTRAN lets you use a variable as a bound in an array declaration, in this special case. That probably wouldn't be too hard to add to C; in fact it might be possible to generalize it to allow *any* nonstatic array declaration to have variable size (within reason). Another advantage of FORTRAN is implicit DO loops in I/O statements, and the related ability to use (constant, at least) repeat counts in FORMATs. I had a program that made this painfully clear when it was translated from FORTRAN to C. Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint
guy@sun.uucp (Guy Harris) (05/28/86)
> That probably wouldn't be too hard to add to C; in fact it might be possible > to generalize it to allow *any* nonstatic array declaration to have variable > size (within reason). Where "within reason" presumably includes "not inside a structure declaration". Even just having "auto" arrays with variable size would mean that the offset of an "auto" variable from the stack/frame pointer would not necessarily be a constant. What about in a "typedef" (or would that be treated as a static declaration)? -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.arpa
dgary@ecsvax.UUCP (D Gary Grady) (05/28/86)
In article <853@bentley.UUCP> kwh@bentley.UUCP (KW Heuer) writes: >In article <1594@ecsvax.UUCP> ecsvax!dgary (D Gary Grady) writes: [listing advantages of FORTRAN over C for scientific work] >>o A richer set of floating point operators, including exponentiation and >> the so-called "in-line" functions (many of which ARE in C). > >I think you mean "builtin" rather than "inline". I don't even consider that >a significant difference, much less an advantage of FORTRAN. No, I meant "inline." That's a standard FORTRAN term and I'm surprised you're not familiar with it. Anyway, the in-line functions in FORTRAN include absolute value, imaginary part (of a complex number), real part (ditto), complex conjugate, explicit truncation, explicit rounding, mod, sign, positive difference, type conversion, maximum, minimum, and various Boolean ones. As I said before, many of these are in C as well, but the FORTRAN set is certainly richer in those used for scientific coding. Whether you consider it a significant difference depends on the kind of programming you do. As for an explicit exponentiation operator, your own comments about C's serious limitations constitute an adequate justification for its addition to the language, I'd say. >>o A way of passing different-sized multidimensional arrays to the same >> subroutine. >Again, this is merely a syntactic quibble -- what FORTRAN does is equivalent >to the one-dimensional "trick", but it's hidden from the user. Quibble? We're talking about a hard-coded subscript calculation every time you refer to an array element. If it isn't hard to add to the language (and I agree it shouldn't be), why not add it (as long as we are talking about language modifications - I understand the view that we should beware Creeping Featurism). Interesting suggestion you make that we might as well extend this to malloc'ed arrays. Hmm... -- D Gary Grady Duke U Comp Center, Durham, NC 27706 (919) 684-3695 USENET: {seismo,decvax,ihnp4,akgua,etc.}!mcnc!ecsvax!dgary
dgary@ecsvax.UUCP (D Gary Grady) (05/28/86)
In my last two postings I used the term "in-line" with respect to
FORTRAN functions and it occurs to me a quick explanation might be in
order. An "in-line function" is one that a compiler expands into
in-line machine language as opposed to a procedure call. Where speed
is of the essence (as it often is in FORTRAN programs), this can make a
significant difference on some machines. FORTRAN programmers have to
worry about a given function being "in-line" or "out-of-line" if they
want to create one of the same name. Thus in-line function names
effectively constitute the only "reserved words" in FORTRAN.
In addition to the in-line functions, FORTRAN has many other "built-in"
functions, that is, those that are a defined part of the language.
This means that these scientific function names are identical over all
implementations of the language, a very important consideration in
writing huge programs that will be used at many sites on different
equipment.
--
D Gary Grady
Duke U Comp Center, Durham, NC 27706
(919) 684-3695
USENET: {seismo,decvax,ihnp4,akgua,etc.}!mcnc!ecsvax!dgarypeters@cubsvax.UUCP (Peter S. Shenkin) (05/28/86)
In article <bentley.853> kwh@bentley.UUCP (KW Heuer) writes: >Another advantage of FORTRAN is implicit DO loops in I/O statements, and the >related ability to use (constant, at least) repeat counts in FORMATs. I had >a program that made this painfully clear when it was translated from FORTRAN >to C. I agree; on the other hand, what C has over FORTRAN in this regard is the ability to keep writing on the same line in subsequent calls to printf(); that is, to *not* insert a newline after WRITEing. Peter S. Shenkin Columbia Univ. Biology Dept., NY, NY 10027 {philabs,rna}!cubsvax!peters cubsvax!peters@columbia.ARPA
bzs@bu-cs.UUCP (Barry Shein) (05/29/86)
>FORTRAN lets >you use a variable as a bound in an array declaration, in this special case. >That probably wouldn't be too hard to add to C; in fact it might be possible >to generalize it to allow *any* nonstatic array declaration to have variable >size (within reason). If I remember right DMR said that at some point in time automatic arrays with variable sizes was in C but they took it out, not sure why though. I think he said in the early C compilers it was a matter of removing a comment or thereabouts to re-enable (memory fades...) About the only major complication I see (and this may have been the original problem) is error handling. Not sure exactly what would happen if it were impossible to allocate the automatic (then again, that can come up now, I guess it's just a SIGSEGV or some such, but kinda weird to recover from, hmm, interesting.) Portability? no, I really can't think of any reason, it can't vary during the activation of the routine so you just adjust the stack via a variable rather than a constant (an extra add instruction per var array, big deal...) No, oh well, seems easy to me, whadidimiss? -Barry Shein, Boston University
peters@cubsvax.UUCP (Peter S. Shenkin) (05/29/86)
In article <ecsvax.1621> dgary@ecsvax.UUCP (D Gary Grady) writes: >In article <853@bentley.UUCP> kwh@bentley.UUCP (KW Heuer) writes: >>In article <1594@ecsvax.UUCP> ecsvax!dgary (D Gary Grady) writes: >>>o A richer set of floating point operators, including exponentiation and >>> the so-called "in-line" functions (many of which ARE in C). >> >>I think you mean "builtin" rather than "inline". I don't even consider that >>a significant difference, much less an advantage of FORTRAN. > >No, I meant "inline." That's a standard FORTRAN term and I'm surprised >you're not familiar with it. Anyway, the in-line functions in FORTRAN >include absolute value, imaginary part (of a complex number), real part >(ditto), complex conjugate, explicit truncation, explicit rounding, mod, >sign, positive difference, type conversion, maximum, minimum, and... All my FORTRAN books call these *intrinsic* functions. This is equivalent in meaning to "built-in." An "in-line" function sounds more like what would be meant by FORTRAN's *statement* function, which acts, from the point of view of the programmer, more-or-less the same way as a a C macro definition. To those who are about to point out ever-so-kindly that this discussion no longer belongs in net.lang.c, I agree, and, now that I've put in my 2-cents' worth, I suggest that we either all shut up, or move it to net.lang.f77. Peter S. Shenkin Columbia Univ. Biology Dept., NY, NY 10027 {philabs,rna}!cubsvax!peters cubsvax!peters@columbia.ARPA
levy@ttrdc.UUCP (Daniel R. Levy) (05/31/86)
In article <1621@ecsvax.UUCP>, dgary@ecsvax.UUCP (D Gary Grady) writes: >In article <853@bentley.UUCP> kwh@bentley.UUCP (KW Heuer) writes: >>In article <1594@ecsvax.UUCP> ecsvax!dgary (D Gary Grady) writes: >[listing advantages of FORTRAN over C for scientific work] >>>o A way of passing different-sized multidimensional arrays to the same >>> subroutine. >>Again, this is merely a syntactic quibble -- what FORTRAN does is equivalent >>to the one-dimensional "trick", but it's hidden from the user. >Quibble? We're talking about a hard-coded subscript calculation every >time you refer to an array element. If it isn't hard to add to the >language (and I agree it shouldn't be), why not add it (as long as we >are talking about language modifications - I understand the view that we >should beware Creeping Featurism). Interesting suggestion you make that >we might as well extend this to malloc'ed arrays. Hmm... Well, this looks like a discussion on both fronts, Fortran versus C and how C could be enhanced. I can't understand Grady's point about "hard-coded subscript calculation" except that true, the programmer in C would need to enter in the code to do the subscript calculations to get the appropriate single subscript, while the Fortran compiler generates this code automatically for its 'multiple-dimension' arrays. But even in C, this programming effort could be eased by using the prepro- cessor, though some concentration would have to go into writing the #define correctly: routin_(i,j,k,d) /* SUBROUTINE ROUTIN(I,J,K,D) */ int i, j, k; /* yeah I know *i *j and *k if interfacing with f77 */ double *d; /* want to treat like a DOUBLE PRECISION D(I,J,K) */ { #define D(m,n,o) d[m+(i * (n-1))+(i * j * (o-1))-1] /* YECH :-) */ /* or d[m+(i * n)+(i * j * o)-i-(i * j)-1] */ stuff_(D(3,4,5)); /* CALL STUFF(D(3,4,5)) */ /* yeah I know stuff_(&D(3,4,5)) if interfacing with f77 */ ... By the way, this does raise a question in my mind about how the convention of 1, not 0, being the lower bound subscript for an array is gotten around efficiently in implementations of Fortran. It sounds like it is a royal, CPU- wasting pain to have to subtract that pesky correction factor from the ag- gregate subscript in coming up with an offset for the address of the array element from the base of the array the way Fortran does, unless the computer has a hardwired way of accessing an object in memory based on a base address (base of the array), an offset (calculated from the subscripts), and a correction factor (based on how the array was dimensioned) residing in regis- ters and added together automatically. I think I recall from days of yore in assembly language programming that the IBM 360/370 architecture was set up to allow just this, not surprising for a machine from the original inventors of Fortran. But what about other machines, especially the more powerful (scalar) ones? Do they all share this multiple-offset-addressing capability? (Not that this would be advantageous in Fortran only; C could also use such a feature when accessing multiply- dimensioned arrays of the type "array[][][]...".) >-- >D Gary Grady >Duke U Comp Center, Durham, NC 27706 >(919) 684-3695 >USENET: {seismo,decvax,ihnp4,akgua,etc.}!mcnc!ecsvax!dgary -- ------------------------------- Disclaimer: The views contained herein are | dan levy | yvel nad | my own and are not at all those of my em- | an engihacker @ | ployer or the administrator of any computer | at&t computer systems division | upon which I may hack. | skokie, illinois | -------------------------------- Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa, vax135}!ttrdc!levy
levy@ttrdc.UUCP (Daniel R. Levy) (05/31/86)
In article <477@cubsvax.UUCP>, peters@cubsvax.UUCP (Peter S. Shenkin) writes: >In article <bentley.853> kwh@bentley.UUCP (KW Heuer) writes: >>Another advantage of FORTRAN is implicit DO loops in I/O statements, and the >>related ability to use (constant, at least) repeat counts in FORMATs. I had >>a program that made this painfully clear when it was translated from FORTRAN >>to C. >I agree; on the other hand, what C has over FORTRAN in this regard is the >ability to keep writing on the same line in subsequent calls to printf(); >that is, to *not* insert a newline after WRITEing. >Peter S. Shenkin Columbia Univ. Biology Dept., NY, NY 10027 >{philabs,rna}!cubsvax!peters cubsvax!peters@columbia.ARPA This is probably as much OS-dependent (actually filesystem/device driver dependent) as it is language dependent. Fortran I/O seems to be better suited to record-oriented OS's such as VMS, while C I/O seems to be better suited to stream-oriented OS's like UNIX. True, Fortran 77 doesn't offer a way to keep printing on the same output line once a given WRITE statement has finished, but a (common?) extension (maybe it will be official in a Fortran 88?) is to allow the edit descriptor '$' in a format statement to signify that the current record has not yet been completely written. VMS Fortran and UNIX f77 both support this, and I must say that UNIX f77 does it better in that it supports this kind of operation when writing to files or to a terminal, while VMS Fortran can only support it when writing to a terminal (being locked into a record-oriented filesystem treatment--once you've finished writing to that record, that's it buddy). -- ------------------------------- Disclaimer: The views contained herein are | dan levy | yvel nad | my own and are not at all those of my em- | an engihacker @ | ployer or the administrator of any computer | at&t computer systems division | upon which I may hack. | skokie, illinois | -------------------------------- Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa, vax135}!ttrdc!levy
dgary@ecsvax.UUCP (D Gary Grady) (05/31/86)
In article <478@cubsvax.UUCP> peters@cubsvax.UUCP (Peter S. Shenkin) writes: >All my FORTRAN books call these *intrinsic* functions. This is equivalent >in meaning to "built-in." An "in-line" function sounds more like what would >be meant by FORTRAN's *statement* function . . . The term "intrinsic" is relatively new to FORTRAN; my late-60s manuals have never heard of it. "Intrinsic" and "in-line" (the older term, still in use among us aging geezers) are synonyms, meaning function names known to and handled by the compiler (or at least eligible for such treatment). For what it's worth, IBM's VS FORTRAN language reference manual uses "intrinsic" and "in-line" more-or-less interchangeably. "Built-in," on the other hand, is poorly defined and could reasonably be interpreted to mean functions that are a defined part of the FORTRAN language and hence "built in" to it. You're right, of course, that this no longer belongs in net.lang.c, and I'm sorry I started it (by trying to point out what changes to C would make it a better successor to FORTRAN as a language for science and engineering). -- D Gary Grady Duke U Comp Center, Durham, NC 27706 (919) 684-3695 USENET: {seismo,decvax,ihnp4,akgua,etc.}!mcnc!ecsvax!dgary
barmar@mit-eddie.MIT.EDU (Barry Margolin) (06/02/86)
In article <900@ttrdc.UUCP> levy@ttrdc.UUCP (Daniel R. Levy) writes: >By the way, this does raise a question in my mind about how the convention >of 1, not 0, being the lower bound subscript for an array is gotten around >efficiently in implementations of Fortran. In the case of one-dimensional arrays, of course, it can be handled at compile time. A good optimizer can also recognize the common patterns of looping over multidimensional arrays, so that the offset can be simply incrememented rather than requiring subscript calculations on each iteration (some of the earliest work on Fortran compilers involved this type of optimization). > It sounds like it is a royal, CPU- >wasting pain to have to subtract that pesky correction factor from the ag- >gregate subscript in coming up with an offset for the address of the array >element from the base of the array the way Fortran does, unless the computer >has a hardwired way of accessing an object in memory based on a base address >(base of the array), an offset (calculated from the subscripts), and a >correction factor (based on how the array was dimensioned) residing in regis- >ters and added together automatically. >I think I recall from days of yore in assembly language programming that >the IBM 360/370 architecture was set up to allow just this, not surprising >for a machine from the original inventors of Fortran. But what about other >machines, especially the more powerful (scalar) ones? Do they all share this >multiple-offset-addressing capability? (Not that this would be advantageous >in Fortran only; C could also use such a feature when accessing multiply- >dimensioned arrays of the type "array[][][]...".) I think many mainframes have such addressing modes. -- Barry Margolin ARPA: barmar@MIT-Multics UUCP: ..!genrad!mit-eddie!barmar
ken@njitcccc.UUCP (Kenneth Ng) (06/02/86)
In article <477@cubsvax.UUCP>, peters@cubsvax.UUCP (Peter S. Shenkin) writes: > In article <bentley.853> kwh@bentley.UUCP (KW Heuer) writes: > > > I agree; on the other hand, what C has over FORTRAN in this regard is the > ability to keep writing on the same line in subsequent calls to printf(); > that is, to *not* insert a newline after WRITEing. Try looking up what the "+" in column 1 does in the format. It supresses the carriage advance. The nestablility of the format enables some very fancy tricks to be used in formating output. In my 18 line fortran game of life I printed the header, put stars around the grid, printed the grid, and did a top of form on every other generation, using one format and one write statement. -- Kenneth Ng: uucp(unreliable) ihnp4!allegra!bellcore!njitcccc!ken bitnet(prefered) ken@njitcccc.bitnet New Jersey Institute of Technology Computerized Conferencing and Communications Center Newark, New Jersey 07102 Vulcan jealousy: "I fail to see the logic in prefering Stonn over me" Number 5: "I need input"
dgary@ecsvax.UUCP (D Gary Grady) (06/02/86)
In article <900@ttrdc.UUCP> levy@ttrdc.UUCP (Daniel R. Levy) writes: >I can't understand Grady's point about "hard-coded subscript calculation" >except that true, the programmer in C would need to enter in the code to >do the subscript calculations to get the appropriate single subscript, That WAS my point; it's harder to write and to read than something more straightforward. As you note, the preprocessor can be used to improve readability somewhat, but you still wind up with something inconsistent with local multidimensional arrays. If you think this is a trivially picky objection, you probably haven't had a lot of experience trying to convince scientists there's more to life than Fortran. >By the way, this does raise a question in my mind about how the convention >of 1, not 0, being the lower bound subscript for an array is gotten around >efficiently in implementations of Fortran. It depends on the compiler, but the basic idea is to do an algebraic rearrangement of the subscript calculation. A simple example avoiding such details as element-width should suffice to make this clear: Given a 2-d array dimensioned (M, N) from which you want the element (i,j), you need to compute: base + (i-1) + n*(j-1) A bit of algebra gives us: base - 1 - n + n*i + j the first three terms of which are in principle computable at compile time. A common trick is to use that value in place of the actual base address, and generate code as if the array subscripts did start at zero. In practice, alas, this is sometimes not possible (consider the case of a huge n). In that event we must take consolation in the fact that decrements are fast and cheap. -- D Gary Grady Duke U Comp Center, Durham, NC 27706 (919) 684-3695 USENET: {seismo,decvax,ihnp4,akgua,etc.}!mcnc!ecsvax!dgary
levy@ttrdc.UUCP (Daniel R. Levy) (06/04/86)
In article <178@njitcccc.UUCP>, ken@njitcccc.UUCP (Kenneth Ng) writes: >In article <477@cubsvax.UUCP>, peters@cubsvax.UUCP (Peter S. Shenkin) writes: >> In article <bentley.853> kwh@bentley.UUCP (KW Heuer) writes: >> I agree; on the other hand, what C has over FORTRAN in this regard is the >> ability to keep writing on the same line in subsequent calls to printf(); >> that is, to *not* insert a newline after WRITEing. >Try looking up what the "+" in column 1 does in the format. >It supresses the carriage advance. The nestablility of the >format enables some very fancy tricks to be used in formating >output. In my 18 line fortran game of life I printed the header, >put stars around the grid, printed the grid, and did a top of form >on every other generation, using one format and one write statement. >Kenneth Ng: uucp(unreliable) ihnp4!allegra!bellcore!njitcccc!ken _18 line_ fortran game of life? Can you post that (in net.lang.f77 of course)? -- ------------------------------- Disclaimer: The views contained herein are | dan levy | yvel nad | my own and are not at all those of my em- | an engihacker @ | ployer or the administrator of any computer | at&t computer systems division | upon which I may hack. | skokie, illinois | -------------------------------- Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa, vax135}!ttrdc!levy
zben@umd5.UUCP (06/05/86)
In article <2157@mit-eddie.MIT.EDU> barmar@mit-eddie.UUCP (Barry Margolin) : >In article <900@ttrdc.UUCP> levy@ttrdc.UUCP (Daniel R. Levy) writes: >>By the way, this does raise a question in my mind about how the convention >>of 1, not 0, being the lower bound subscript for an array is gotten around >>efficiently in implementations of Fortran. >>... pain to have to subtract that pesky correction factor from the ag- >>gregate subscript in coming up with an offset for the address of the array >>element from the base of the array the way Fortran does, unless the computer >>has a hardwired way of accessing an object in memory based on a base address >>(base of the array), an offset (calculated from the subscripts), and a >>correction factor (based on how the array was dimensioned) residing in regis- >>ters and added together automatically. >I think many mainframes have such addressing modes. Of course, the simplest method of doing this is to decrease the base address of the array by the correction factor. This tack is taken on the Sperry 1100. The major problem with it is making sure that the <base-offset> does not go negative, as the two high bits in the address field on the Sperry enable the automatic incrementation of the index register [i.e. (*p++) ] and indirecting which can cause really funny things to happen. So, the software kluge is that the compiler can create something called a "minadr specification" in the relocatable binary, and the system linking loader interprets that as a request to relocate that array "no lower than" the specified address. In the worst case it might have to move the segment [Sperry calls them "banks"] start address above the default 40000 (8)... Then there was the user who said: CASE ZIPCODE OF 20904: ROUTE1; 20905: ROUTE2; 20906: ROUTE3; and made the Pascal compiler generate [J $-20903,X] without a "minadr"... -- "We're taught to cherish what we have | Ben Cranston by what we have no longer..." | zben@umd2.umd.edu ...{seismo!umcp-cs,ihnp4!rlgvax}!cvl!umd5!zben
liberte@uiucdcsb.CS.UIUC.EDU (06/09/86)
This discussion reminds me of when I had to write a program (in FORTRAN) to manipulate an array with a dynamically specified number of DIMENSIONS, as well as dynamically specified size of each dimension. Only APL would have helped (that I know of). Dan LaLiberte liberte@b.cs.uiuc.edu liberte@uiuc.csnet ihnp4!uiucdcs!liberte
dgary%mcnc.csnet@CSNET-RELAY.ARPA (06/09/86)
My apologies. In my defense I was just letting rn pull the attribution out of the header. I should have checked, though.
rgh%inmet.uucp@BRL.Arpa (06/10/86)
GVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGV From: Barry Margolin <barmar@mit-eddie.ARPA> Subject: Re: C vs. FORTRAN (was: What should be added to C) To: info-c@BRL-SMOKE.ARPA Return-Path: <info-c-request@BRL.ARPA> Redistributed: Xerox-Info-C^.x@XEROX.ARPA Received: from BRL-AOS.ARPA by Xerox.COM ; 02 JUN 86 16:44:00 PDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a015999; 2 Jun 86 17:29 EDT Received: from USENET by SMOKE.BRL.ARPA id a005720; 2 Jun 86 17:02 EDT Newsgroups: net.lang.c Message-ID: <2157@mit-eddie.MIT.EDU> GVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGV In article <900@ttrdc.UUCP> levy@ttrdc.UUCP (Daniel R. Levy) writes: >By the way, this does raise a question in my mind about how the convention >of 1, not 0, being the lower bound subscript for an array is gotten around >efficiently in implementations of Fortran. In the case of one-dimensional arrays, of course, it can be handled at compile time. A good optimizer can also recognize the common patterns of looping over multidimensional arrays, so that the offset can be simply incrememented rather than requiring subscript calculations on each iteration (some of the earliest work on Fortran compilers involved this type of optimization). > It sounds like it is a royal, CPU- >wasting pain to have to subtract that pesky correction factor from the ag- >gregate subscript in coming up with an offset for the address of the array >element from the base of the array the way Fortran does, unless the computer >has a hardwired way of accessing an object in memory based on a base address >(base of the array), an offset (calculated from the subscripts), and a >correction factor (based on how the array was dimensioned) residing in regis- >ters and added together automatically. >I think I recall from days of yore in assembly language programming that >the IBM 360/370 architecture was set up to allow just this, not surprising >for a machine from the original inventors of Fortran. But what about other >machines, especially the more powerful (scalar) ones? Do they all share this >multiple-offset-addressing capability? (Not that this would be advantageous >in Fortran only; C could also use such a feature when accessing multiply- >dimensioned arrays of the type "array[][][]...".) I think many mainframes have such addressing modes. -- Barry Margolin ARPA: barmar@MIT-Multics UUCP: ..!genrad!mit-eddie!barmar
rgh%inmet.uucp@BRL.Arpa (06/10/86)
GVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGV From: Root Boy Jim <rbj@ICST-CMR.ARPA> To: brl.arpa!gwyn@seismo.css.gov, dgary%ecsvax.uucp@BRL.ARPA, ecsvax!dgary@mcnc.CSNET Subject: Re: C vs. FORTRAN (was: What should be added to C) Cc: info-c@BRL-SMOKE.ARPA Return-Path: <info-c-request@BRL.ARPA> Redistributed: Xerox-Info-C^.x@XEROX.ARPA Received: from BRL-AOS.ARPA by Xerox.COM ; 03 JUN 86 19:30:16 PDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a004397; 3 Jun 86 20:13 EDT Received: from icst-cmr.arpa by SMOKE.BRL.ARPA id a008635; 3 Jun 86 20:01 EDT Received: by icst-cmr.ARPA (4.12/4.7) id AA16302; Tue, 3 Jun 86 19:57:33 edt Message-Id: <8606032357.AA16302@icst-cmr.ARPA> GVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGV There are a number of good reasons for building integer exponents into the language, one of which is the possibilities for optimization. An Doug, I am surprised that you ignored DMR's rationale for not putting exponentiation into C, or were you merely requesting a library function. Yes, I know you didn't write this but I'm responding to you here anyway. obvious one is converting x**3 into x*x*x, not to mention having the compiler recognise at what level one should not do this optimization. More subtle is the use of "algebraic" optimizations. For instance, converting a*x**3 + b*x**2 + c*x + d to d + x * (c + x * (b + a*x)) which replaces eight multiplications with three and not only executes faster but (most of the time) greatly reduces precision problems. Granted that this can be coded by the programmer; how many do you think will actually do it? Yup... Anyone who wants the benefits. It could be argued that by allowing programs to be optimised, you promote laziness in coding techniques. In this example, the notation looks quite similar to the original form, especially if you write it backwards. Any optimizer smart enuf to make this transformation should be able to do the same for the longhand as well: a*x*x*x + ... By making it harder to code poorly, you make it harder to code well by comparison. Don't give away all our wizardly secrets :-) (Root Boy) Jim Cottrell <rbj@cmr> - if it GLISTENS, gobble it!!
ken@njitcccc.UUCP (Kenneth Ng) (06/11/86)
In article <914@ttrdc.UUCP>, levy@ttrdc.UUCP (Daniel R. Levy) writes: > _18 line_ fortran game of life? Can you post that (in net.lang.f77 of course)? It's been quite some time since my school account was rolled out into the bit bucket, therefore I had to reconstruct this from scratch, but its pretty close. The school compiler I used allowed fortran programs to not have the "STOP" and "END" statements, although it generated warnings. INTEGER A(10,10)/100*0/, B(10,10), C(10,10) READ(5,10)((A(I,J),J=2,9),I=2,9) 10 FORMAT(8I1) DO 100 COUNT = 1,50 DO 50 I = 2,7 DO 50 J = 2,7 SUM=A(I-1,J-1)+A(I-1,J)+A(I-1,J+1)+A(I,J-1)+A(I,J+1) >+A(I+1,J-1)+A(I+1,J)+A(I+1,J+1) B(I,J)=0 50 IF(SUM.EQ.3).OR.((SUM+A(I,J)).EQ.3)B(I,J)=1 DO 60 I=2,9 DO 60 J=2,9 C(I,J) = ' ' IF (B(I,J).EQ.1)C(I,J) = '*' 60 A(I,J) = B(I,J) 100 WRITE(6,70)COUNT,((C(I,J),J=2,9),I=2,9) 70 FORMAT('1 Gen ',I3,/,'0',8('*'),/,8(' |',8A1,'|',/),'0',8('*'),/) STOP END -- Kenneth Ng: uucp(unreliable) ihnp4!allegra!bellcore!njitcccc!ken bitnet(prefered) ken@njitcccc.bitnet New Jersey Institute of Technology Computerized Conferencing and Communications Center Newark, New Jersey 07102 Vulcan jealousy: "I fail to see the logic in prefering Stonn over me" Movie "Short Circuit": Number 5: "I need input"
peters@cubsvax.UUCP (Peter S. Shenkin) (06/11/86)
In article <uiucdcsb.139200030> liberte@uiucdcsb.CS.UIUC.EDU writes: > >This discussion reminds me of when I had to write a program (in FORTRAN) >to manipulate an array with a dynamically specified number of DIMENSIONS, >as well as dynamically specified size of each dimension. Only APL would >have helped (that I know of). My initial thought was: of course you can do this in C, using a linear array and explicit pointer arithmetic, rather than array notation; on the other hand you can do this just as easily in FORTRAN, using a linear array and the identical arithmetic (modulo array origin!) on the *index* into the array.... Peter S. Shenkin Columbia Univ. Biology Dept., NY, NY 10027 {philabs,rna}!cubsvax!peters cubsvax!peters@columbia.ARPA
gwyn@brl-smoke.ARPA (Doug Gwyn ) (06/15/86)
In article <1253@brl-smoke.ARPA> rgh%inmet.uucp@BRL.Arpa writes:
-GVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGV
-From: Root Boy Jim <rbj@ICST-CMR.ARPA>
-Doug, I am surprised that you ignored DMR's rationale for not putting
-exponentiation into C, or were you merely requesting a library function.
-Yes, I know you didn't write this but I'm responding to you here anyway.
What in the world does the last sentence mean?? And who wrote it???
This has passed over the borderline separating reality from fantasy..
In any case, the reason for not including exponentiation in the language
directly is that it would obscure the otherwise evident fact that this
is an expensive operation. There is nothing preventing an implementor
from recognizing lpow(a,b) (or, better, _lpow(a,b)) as a special case
and generating in-line code if he has hardware that directly implements
integer exponentiation. I don't know of any machines like that, though.
The implementor should of course also provide a portable C source for
lpow()/_lpow() so that applications can be ported to other machines.
I hope to get around to writing and posting a portable lpow() soon.