Re: Fortran Myths & Disinformation Wanted

Re: Fortran Myths & Disinformation Wanted

[essoft]

Dan Tex1 wrote:

> >> Fortran can also be fairly terse, if you just use the f77 way:
> >>
> >>   function f(a, x)
> >>     g(x) = 1-a*x**2
> >>     f = sin(g(2*x)) - cos(g(x/2))
> >>   end
> >
> >That example is a little too simple to be interesting. Anyway,
> >here is the Ada 95 version:
> >
> >with Ada.Numerics.Elementary_Functions;
> >use  Ada.Numerics.Elementary_Functions;
> >
> >function F (A, X: Float) return Float is
> >
> >   function G (X: Float) return Float is
> >   begin
> >      return 1.0-A*X**2;
> >   end G;
> >begin
> >   return Sin(G(2.0*X))-Cos(G(X/2.0));
> >end F;
> >
>
> I've heard some good things about Ada.   However,  I've never seen any Ada code
> until now.   Looking at the example above though....  for simple mathematical
> manipulations at least...  I think I'll stick with Fortran.   I find the above
> Ada example to be a bit too verbose and "non-natural" to read.  Is the rest of
> the language like that?

It gets worse exponentially -- a few years back I saw a rotational dynamics problem
OOPed in ADA and in a "Fortran style**" ADA  -- thirty pages of code vs page and a
half, that would've shrunk further had it been in Fortran...  Just like a picture
is worth a thousand words, so are the little parallel code snippets that should
periodically be shipped to disciples elsewhere... after all, seeing is believing!?


**  Before giving in to the packaging urge and start hiding everything in sight in
where_in_hell_is _that damn_thing_package.  Oh yes, they love verbosity -- you're
lucky if you can find some actual code here and there...

--
Dr.B.Voh
-----------------------------------------------
Modeling * Simulation * Analysis
http://www.netcom.com/~essoft
-----------------------------------------------

Re: Fortran Myths & Disinformation Wanted

[Mike Silva]

How ironic that Dr.B.Voh chose this particular thread to toss his
stinkbomb into comp.lang.ada.  Is this something EFPK?

essoft@ix.netcom.com wrote:
> It gets worse exponentially -- a few years back I saw a rotational dynamics problem
> OOPed in ADA and in a "Fortran style**" ADA  -- thirty pages of code vs page and a
> half, that would've shrunk further had it been in Fortran...  Just like a picture
> is worth a thousand words, so are the little parallel code snippets that should
> periodically be shipped to disciples elsewhere... after all, seeing is believing!?
> 
> **  Before giving in to the packaging urge and start hiding everything in sight in
> where_in_hell_is _that damn_thing_package.  Oh yes, they love verbosity -- you're
> lucky if you can find some actual code here and there...
> 
> --
> Dr.B.Voh

Re: Fortran Myths & Disinformation Wanted

[Robert I. Eachus]

   > Fortran can also be fairly terse, if you just use the f77 way:

   function f(a, x)
      g(x) = 1-a*x**2
      f = sin(g(2*x)) - cos(g(x/2))
   end

   > >That example is a little too simple to be interesting. Anyway,
   > >Here is the Ada 95 version: {reformatted for clarity}

   with Ada.Numerics.Elementary_Functions;
   use Ada.Numerics.Elementary_Functions;
   function F (A, X: Float) return Float is
     function G (X: Float) return Float is begin return 1.0-A*X**2; end G;
   begin return Sin(G(2.0*X))-Cos(G(X/2.0)); end F;

   Looked at this way the difference in size is obviously due to
requiring all declarations to be explicit, and some added reserved
words (begin and return).  Of course, you might want to use (Fortran)
double or (Ada) Long_Float instead.  In the Ada version you just have
to add Long_ in six places (and the compiler will scold you if you
miss one) while in Fortran you have to replace implicit declarations
with explicit declarations and hope you don't miss one.

   There should be no difference in generated code between the two
versions, so the tradeoff is the traditional Ada tradeoff of more
required text to reduce errors and make maintenance easier.  If you
don't care about maintenance, use APL which is even terser than
Fortran.  I do.--I find that I program in four languages consistantly,
of all the languages I know: Ada for anything that needs to be read or
maintained, SQL for database queries, csh for shell scripts and APL
for exploratory data analysis.  (Please, no arguments about csh versus
sh, bash, or tsh.  I use all of them, but my job requires mostly csh.
Similarly, I prefer ODBC for embedded database access, but most of my
database access coding is in the form of standalone scripts.)

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Fortran Myths & Disinformation Wanted

[bglbv]

eachus@spectre.mitre.org (Robert I. Eachus) writes:

>    > Fortran can also be fairly terse, if you just use the f77 way:
> 
>    function f(a, x)
>       g(x) = 1-a*x**2
>       f = sin(g(2*x)) - cos(g(x/2))
>    end
> 
>    > >That example is a little too simple to be interesting. Anyway,
>    > >Here is the Ada 95 version: {reformatted for clarity}
> 
>    with Ada.Numerics.Elementary_Functions;
>    use Ada.Numerics.Elementary_Functions;
>    function F (A, X: Float) return Float is
>      function G (X: Float) return Float is begin return 1.0-A*X**2; end G;
>    begin return Sin(G(2.0*X))-Cos(G(X/2.0)); end F;
> 
>    Looked at this way the difference in size is obviously due to
> requiring all declarations to be explicit, and some added reserved
> words (begin and return).

Yes. Note that the full-fledged Fortran 95 version with explicit
declarations and an internal procedure replacing the statement
function reads:
   REAL FUNCTION F (A, X)
      IMPLICIT NONE
      REAL, INTENT(IN) :: A, X
      F = SIN(G(2.0*X))-COS(G(X/2.0))
   CONTAINS
      REAL FUNCTION G (X)
         REAL, INTENT(IN) :: X
         G =  1.0-A*X**2
      END FUNCTION G
   END FUNCTION F
which has the same number of lines as my Ada version did before
Robert Eachus reformatted it. And I'll reiterate that this example
is too simple to be interesting, in that it is not representative
of most numerical analysis code. Statement functions are not *that*
common in practice, and subprograms tend to be longer (which makes
IMPLICIT NONE more valuable than in this example).

One thing this example shows is that Fortran is actually among
the more verbose languages out there. The verbosity was gained in
recent revisions of the language, and comes from features added to
make debugging and automated checking easier. On the other hand
Fortran 90/95 added features that promote higher code density,
in primis array operations. This corresponds to what Robert Dewar
has called a "higher level of abstraction"; I'm not sure whether he
had Fortran 77 or Fortran 95 in mind when making his claim that
Ada had an advantage on that count. (And I won't go into the merits
of that claim here.)

In my book, terseness is OK when a program unit is short enough that
I can contemplate it in its entirety in my mind. As soon as it grows
beyond the point where I need to keep written notes, explicitness
begins to win (i.e. I might as well make sure that my notes are
thorough; and if the compiler can understand them and make good use
of them in its diagnostics, so much the better).
> 
>    There should be no difference in generated code between the two
> versions, so the tradeoff is the traditional Ada tradeoff of more
> required text to reduce errors and make maintenance easier.  If you
> don't care about maintenance, use APL which is even terser than
> Fortran.  I do.

And if you do care about maintenance of Fortran code, you may like some
of the new features, even though they come at the expense of terseness.

Re: Fortran Myths & Disinformation Wanted

[Nick Roberts]

Robert I. Eachus wrote in message ...
|If you
|don't care about maintenance, use APL which is even terser than
|Fortran.

And I use Prolog:

g(X,A,Y) :- Y is 1-A*X*X.
f(A,X,Y) :- g(2*X,A,B), g(X/2,A,C), Y is sin(B)-cos(C).

Terse enough for you?

-------------------------------------------
Nick Roberts    "The Prophylactic Didactic"
-------------------------------------------

&IknowtheXposting'sgonnaREALLYannoysomeppl:-)

Re: Fortran Myths & Disinformation Wanted

[Randy MacDonald]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 837 bytes --]

In article <7a490l$snr$2@plug.news.pipex.net>, "Nick Roberts" <Nick.Roberts@dial.pipex.com> wrote:
>Robert I. Eachus wrote in message ...
>|If you
>|don't care about maintenance, use APL which is even terser than
>|Fortran.
>
>And I use Prolog:
>
>g(X,A,Y) :- Y is 1-A*X*X.
>f(A,X,Y) :- g(2*X,A,B), g(X/2,A,C), Y is sin(B)-cos(C).
>
>Terse enough for you?

nope....
f <- {-/1 2 o. a. {1-a.�w.*2} w. � 2 0.5}  -- APL with dynamic functions

--
|\/| Randy A MacDonald       |"We ARE the weirdos, mister!"
|\\| randy@godin.on.ca       |        Fairuza Balk "The Craft"
     BSc(Math) UNBF '83      | APL: If you can say it, it's done.
     Natural Born APL'er     | *** GLi Info: info@godin.on.ca ***
     I use Real J            | Also http://www.godin.com/godin/
------------------------------------------------<-NTP>----{ gnat }-

Re: Fortran Myths & Disinformation Wanted

[robert_dewar]

In article <36C3BEA7.F96F80FC@ix.netcom.com>,
  essoft@ix.netcom.com wrote:
> It gets worse exponentially -- a few years back I saw a
> rotational dynamics problem OOPed in ADA and in a
> "Fortran style**" ADA  -- thirty pages of code vs page
> and a half, that would've shrunk further had it been in
> Fortran...

Be careful with comparative examples of this kind. They
almost always involve apples and oranges comparisons of
differing styles, and very often involve comparisons of
well written programs with badly written ones, which
prove nothing.

Having used both Fortran and Ada extensively, I would say
that the more powerful abstraction features of Ada are
likely to be significantly valuable in improving the
reliability, readability and maintainability of any large
numerical code, assuming competent programming in both
language domains.

I also think that the fact that Ada has a well thought out
model for floating-point semantics (Fortran has none) can
be of vital importance in numerical codes that are at the
level of carefully worrying about error propagation. It is
impossible to write such code in Fortran in a formally
portable manner.

Examples of snippets, "look at these 5 lines in language X,
how would you do this in language Y" are almost always
bogus. One has to look at large examples, well programmed.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Fortran Myths & Disinformation Wanted

[bglbv]

cnahr@seemysig.invalid (Christoph Nahr) writes:

> >with Ada.Numerics.Elementary_Functions;
> >use  Ada.Numerics.Elementary_Functions;

> Unashamed off-topic question: Why exactly do you have to write *two*
> lines to use *one* Ada library?

I'm cross-posting this response to comp.lang.ada, where the question
would have been on-topic (albeit a FAQ).

The answer is: you don't need the second statement ("use") if you only
want to use fully qualified names, as in

   return Ada.Numerics.Elementary_Functions.Sin(G(2.0*X)) -
          Ada.Numerics.Elementary_Functions.Cos(G(X/2.0));

Likewise, when you only want to import a few selected identifiers
from the with'ed package, you can simply give them shorthand names:

   function Sin (X: Float) return Float
      renames Ada.Numerics.Elementary_Functions.Sin;
   -- and likewise for Cos

One can also do the renaming at a higher level:

   package EF renames Ada.Numerics.Elementary_Functions;
-- ...
   return EF.Sin(G(2.0*X))-EF.Cos(G(X/2.0));

An additional twist is that you can (indeed must) "with" a package
at the compilation unit level, but are allowed to "use" it only
within more limited scopes.

> Clumsy attempt to make this question on-topic: After all, Fortran
> 90/95 only has the USE statement and seems to do fine. :-)

That's one of the things the committee that developed Fortran 90
tried to keep simple. They were well aware of Ada 83 syntax at the
time.

Whether the adopted solution is appropriate is (as always) debatable.
Suffice it to say that Fortran did not go for the hierarchical naming
scheme of Ada, and that once you remove that feature the distinction
between "with" and "use" becomes blurred. On the other hand, Fortran
offers renaming and ONLY: clauses on the USE statement (and nowhere
else). Also, Fortran defaults to reexporting objects that are visible
by use association within a module; you have to explicitly make them
PRIVATE to prevent this. By contrast, Ada packages won't reexport such
entities unless they've been explicitly renamed within the package.

Fortran lets you put a damper on namespace pollution through ONLY:
clauses on USE statements and through the PRIVATE attribute, while Ada
does that by defaulting to a fully qualified hierarchical namespace
and giving you a couple of ways of creating abbreviations, namely "use" 
and "renames". Neither solution is perfect, but both are workable in
practice.

Since this is going to two newsgroups whose readers need not all be
familiar with both Ada 95 and Fortran 95, a few examples may be
useful.

! Fortran                            -- Ada

MODULE inner                         package Inner is
   PUBLIC
   REAL :: a, b, c                      A, B, C: Float;
END MODULE inner                     end Inner;

                                     with Inner;
MODULE middle                        package Middle is
   USE inner, ONLY: a, d => c           A: Float renames Inner.A;
                                        D: Float renames Inner.C;
   PUBLIC                              
   INTEGER :: c                         C: Integer;
END MODULE middle                    end Middle;

                                     with Middle;
MODULE outer                         package Outer is
   USE middle                           use Middle; -- optional
   PRIVATE
   PUBLIC :: c                          C: Integer renames Middle.C;
   LOGICAL :: b                         B: Boolean;                         
END MODULE outer                     end Outer;

There. I hope I got it all right (my Ada is a bit rusty). If not,
someone will undoubtedly correct me. The point is that both languages
offer comparable facilities, but there are differences of detail.
I'm not really interested in passing judgment on which is better.
Give that apple to Paris, not to me.

Note that in the example above, INNER  exports A, B, C;
                                MIDDLE exports INNER's A and C (renamed D) 
                                               and MIDDLE's C;
                                OUTER  exports OUTER's B and MIDDLE's C.