From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,c4cb2c432feebd9d X-Google-Thread: 1094ba,c4cb2c432feebd9d X-Google-Attributes: gid103376,gid1094ba,public X-Google-Language: ENGLISH,ASCII Path: g2news2.google.com!news1.google.com!news3.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!wn14feed!worldnet.att.net!bgtnsc05-news.ops.worldnet.att.net.POSTED!b680011b!not-for-mail From: Dick Hendrickson User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada,comp.lang.fortran Subject: Re: Ada vs Fortran for scientific applications References: <0ugu4e.4i7.ln@hunter.axlog.fr> In-Reply-To: <0ugu4e.4i7.ln@hunter.axlog.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Message-ID: NNTP-Posting-Host: 9fd8805a76532287b3023e9ed50178db X-Complaints-To: abuse@worldnet.att.net X-Trace: bgtnsc05-news.ops.worldnet.att.net 1148404143 9fd8805a76532287b3023e9ed50178db (Tue, 23 May 2006 17:09:03 GMT) NNTP-Posting-Date: Tue, 23 May 2006 17:09:03 GMT Organization: AT&T Worldnet Date: Tue, 23 May 2006 17:09:03 GMT Xref: g2news2.google.com comp.lang.ada:4374 comp.lang.fortran:10134 Date: 2006-05-23T17:09:03+00:00 List-Id: Jean-Pierre Rosen wrote: > Disclaimer: > I am an Ada guy. FORTRAN was my first programming language, but it was > long, long ago, and I don't know about the latest improvements to the > language. I'll answer some questions here, but I'd like to be > enlightened on the latest trade from the FORTRAN side. > > Dan Nagle a �crit : > >> Hello, >> >> Jean-Pierre Rosen wrote: >> >>> Nasser Abbasi a �crit : >>> >>>> What are the technical language specific reasons why Fortran would >>>> be selected over Ada? >>>> >>> Some immediate reasons: >>> 1) Packaging. Packages allow better organization of software, which >>> is good for any kind of application. >> >> >> Can you compare and contrast Ada packages >> with Fortran modules and submodules? > > Honestly, I don't know about Fortran modules. I think they're alot like packages. They provide a scope where you can define variables, data types, operators, functions, etc. They can be either PUBLIC or PRIVATE and the USEr of the module can control which ones he imports. They allow for a lot of name and implementation hiding. Data types can have PRIVATE or PUBLIC internal parts, independent of whether or not the data type itself is PUBLIC or PRIVATE. > >>> 2) Strong typing. Scientific applications often deal with physical >>> units, and Ada is great at supporting these. >> >> >> What specific features of Ada provide better support >> than the comparable feature of Fortran? > > Is it possible in Fortran to define three *incompatible* types Length, > Time, and Speed, and define a "/" operator between Length and Time that > returns Speed? Yes, it's possible. There was a long thread inb c.l.f a year or two ago abou this. It's a bit of a pain in the butt to cover all the cases. Is E = m*c**2 the same as E=m*c*c? Fortran 2003 has polymorphic variables which might make it easier to write a complete set of units and operators. That probably would lose some compile time checking. > >>> 3) User defined accuracy. Ada allows you to define the accuracy you >>> need, the compiler chooses the appropriate representation. Note that >>> you are not limited to only two floating point types (many machines >>> have more than that). >> >> >> How is this better than Fortran's kind mechanism? > > I need to be educated about Fortran's kind, but can you use it to > specify that you want a type with guaranteed 5 digits accuracy? Yes, Fortran allows you to specify both decimal precision and exponent range for variables. The compiler must pick the best representation it supports (where "best" is defined in the standard). If it doesn't support the precision or range, it must give an error. > >>> 4) Fixed points. Not available in Fortran >> >> >> Agreed. How important is this for floating point work? >> Fortran is rarely used for imbedded software (at least, >> I wouldn't). > > It's not important for floating point work, it's important for fixed > point work :-) It's not important for Fortran work ;) . Technically, it probably could be done under the KIND mechanism, but I don't think any compiler support it directly. There is enabling stuff coming in F2008. > > Because Fortran has no fixed points, the scientific community sees > floating point as the only way to model real numbers. Actually, fixed > points have nothing to do with embedded software, they are a different > way of modelling real (in the mathematical sense) numbers, with > different numerical properties. Depending on the problem, fixed point > may (or not) be more appropriate. > >>> 5) Guaranteed accuracy, not only for basic arithmetic, but for the >>> whole mathematical library >> >> >> Can you compare Ada's accuracy requirements with Fortran's >> support for IEEE 754? > > Ada's accuracy requirement is independent from any hardware (or > software) implementation of floating points, and are applicable even for > non IEEE machines. Nope. The IEEE features in Fortran 2003 encourage processors to do the right thing, but don't mandate it. What does Ada say about things like COS(1.1E300)? It's unclear to me what that could or should mean on a machine with finite (or at least less than 300 ;) ) digits of precision. > >>> 6) Standardization. All compilers process exactly the same language. >> >> >> Again, how is this different? Fortran compilers are required >> to be able to report use of extensions to the standard. > > AFAIK, there is a formal validation suite for Fortran, but Nope, there isn't a formal validation suite for "modern" Fortran. There was one for FORTRAN 77, but, realistically, it wasn't very good. If you need one, I know where you can get a real good one ;). > 1) Compilers rarely report their validation result > 2) A compiler is deemed "passed" if it succeeds 95% of the tests, while > 100% is required for Ada > >>> 7) Interfacing. Easy to call libraries in foreing languages => all >>> libraries available for Fortran are available for Ada. >> >> >> Can you compare Interfaces.C to ISO_C_BINDING? >> How is one better or worse than the other? > > Sorry, I don't know what you are refering to (except for Interfaces.C :-) The ISO_C_BINDING module specifiecs a raft of C like things, named constants, some procedure interfaces, etc. There is also a BIND(C) attribute for externals that forces the compiler to use a C compatible calling sequence. Between that and the named constants, etc., you can define interfaces to just about any C function and vice-versa. There are some purely Fortran things, like multi-dimensional array sections, that have no defined passing mechanism. > >>> 8) Concurrency, built into the language >> >> >> Co-arrays and concurrent loops are coming in Fortran 2008. > > Concurrency has been in Ada since 1983! Moreover, it's a multi-tasking > model, not concurrent statements model. Both models have benefits and > drawbacks, it depends on the needs. > >> >>> 9) Generics. Stop rewriting these damn sorting routines 1000 times. >> >> >> Intelligent Macros are coming in Fortran 2008. > > I don't know what an "intelligent macro" is, but certainly generics > (once again available since 1983"), are much more than macros, even > intelligent ones. > > For one thing, the legality of generics is checked when the generic is > compiled. This means that, provided actual parameters meet the > requirements of the formals, there is no neeed to recheck at > instantiation time, and ensures that any legal instantiation will work > as expected. AFAIK, this cannot be achieved by macros. This is a flaw (or feature?) of the macro approach. The macro system is Fortran aware, so really stupid things can be caught early on, but most bugs would be caught when a version is instantiated. Basically you define a template-like thing, which can have embedded IF-THEN logic, and instantiate it yourself for whatever set of conditions you need. There's an old joke that says "all compilers are multi-pass optimizers, some of them require the programmer to make the first few passes." In that sense, Fortran's intelligent macros are just like Ada's generics. > >>> 10) Default parameters. Makes complex subprograms (simplex...) much >>> easier to use. >> >> >> Agreed. Agreed also. Fortran subroutines can have optional arguments. However, there's no magic default. The subroutine programmer must check for the absence of an optional argument and do the right thing manually. >> >>> 11) Operators on any types, including arrays. Define a matrix product >>> as "*"... >> >> >> How is Ada's operators for types better or worse than Fortran's? >> Is Ada's "*" operator better than Fortran's matmul()? > > More convenient to write: > Mat1 := Mat2 * Mat3; There's been several comments on this one. Basically, Fortran went the route that all intrinsic operators operate on an element-by-element basis. User defined operators can do whatever is desired. Personally, I think code is hard to read when * sometimes operates one way and sometimes another. But, that's just my opinion. > >>> 12) Bounds checking, with a very low penalty. Makes bounds checking >>> really usable. >> >> >> How is Ada's bounds checking better or worse than Fortran's? > > I may miss something on the Fortran side, but Ada's very precise typing > allows to define variables whose bounds are delimited. If these > variables are later used to index an array (and if the language features > are properly used), the compiler statically knows that no out-of-bound > can occur. In short, most of the time, an Ada compiler is able to prove > that bounds checking is not necessary, and corresponding checks are not > generated. > > In practice, compiling an Ada program with or without bounds checking > shows very little difference in execution speed, because only the really > useful checks are left, all the spurious ones have been eliminated. > Ada's is surely better. Knowing that a subscript has to be in range, because it's checked when a value is assigned to the subscript variable, has to be more efficient than what Fortran can do. In general, Fortran has to check the value of the subscripts on every array reference. In practice, most array references take place in DO loops and compilers can usually hoist the checks outside the loop, so they have minimal cost at run time. Dick Hendrickson