eugene@pioneer.arpa (Eugene N. Miya) (03/11/88)
In article <24861@yale-celray.yale.UUCP> leichter@yale-celray.UUCP (Jerry Leichter) writes: >In article <24737@yale-celray.yale.UUCP> lisper@yale-celray.UUCP (Bjorn Lisper) writes: >>... If we had a language that . . . [comment about access] >>Isn't this a nice argument against using a language like FORTRAN in >>scientific computing? > >Nice theoretical argument - but it ignores the central issue: Maybe the >REASON the scientific community like FORTRAN is that it ALLOWS them to "play >around". In fact, "playing around" is an absolutely standard technique >in many large numerical codes; it's what makes them practical. A common thing >to do is to allocate a large one-dimensional array and carve variable-sized >2-D arrays out of it. The way this is done is ugly, because FORTRAN has no >inherent ability to deal with dynamic memory allocation so it all has to be >faked. <Stuff about malloc and C deleted> > >Before proposing to remove something so central to large codes, you'd better >understand WHY it's central, and what you can provide to replace it with. Well, you are being a little harsh yourself, and I would argue the same thing. Then some one can argue with me (can you say tar pit?). The CIVIC compiler (read CTSS FORTRAN on some Crays) does allow dynamic memory allocation. But more to the pont is that a lot of codes are just artifacts (dusty decks) from days that much of this stuff did not fit on machines. This is why EQUIVALENCE is there. They are also trying to get it out of the language with the greatest resistance. It's playing around, but on a massive program scale. From the Rock of Ages Home for Retired Hackers: --eugene miya, NASA Ames Research Center, eugene@ames-aurora.ARPA "You trust the `reply' command with all those different mailers out there?" "Send mail, avoid follow-ups. If enough, I'll summarize." {uunet,hplabs,hao,ihnp4,decwrl,allegra,tektronix}!ames!aurora!eugene
fpst@hubcap.UUCP (Steve Stevenson) (03/11/88)
in article <5814@ames.arpa>, eugene@pioneer.arpa (Eugene N. Miya) says: > In article <24861@yale-celray.yale.UUCP> leichter@yale-celray.UUCP (Jerry Leichter) writes: >>In article <24737@yale-celray.yale.UUCP> lisper@yale-celray.UUCP (Bjorn Lisper) writes: >>>... If we had a language that . . . [comment about access] >>>Isn't this a nice argument against using a language like FORTRAN in >>>scientific computing? >> >>Nice theoretical argument - but it ignores the central issue: Maybe the >>REASON the scientific community like FORTRAN is that it ALLOWS them to "play >>around". In fact, "playing around" is an absolutely standard technique >>in many large numerical codes; it's what makes them practical. > But more to the pont is that a lot of codes are just artifacts > (dusty decks) from days that much of this stuff did not fit on machines. > This is why EQUIVALENCE is there. They are also trying to get it out of the > language with the greatest resistance. It's playing around, but on > a massive program scale. I'd take exception to each view. For example, take something like Gauss quadrature which needs tridiagonal systems. There is no compiler (that I am aware of) which has "shape = tridiagonal" as a primitive array shape. (I am, however, working on such a system) Please also recall that one of the main walls facing both functional and logic programming is the EFFICIENT implementations of very vanilla numerical codes. By efficient, I mean being able to compute the solution AT ALL. The problem is that assignments are based on known behaviour of the matrix and this actually allows for the program to compute what is supposed to. Otherwise, there isn't enough memory anywhere. The EQUIVALENCE problems comes about because most compiler folks have spent more steam on condeming Fortran, rather than realizing that it should be redone for the specialized numerical use. We don't need to write general software [e.g., accounting systems] in Fortran anymore. The question is how SHOULD we address the numerical problem. -- Steve Stevenson fpst@hubcap.clemson.edu (aka D. E. Stevenson), fpst@clemson.csnet Department of Computer Science, comp.hypercube Clemson University, Clemson, SC 29634-1906 (803)656-5880.mabell