should I be interested in ada?

should I be interested in ada?

[Phillip Helbig]

I'm actually quite happy programming in Fortran95 but Ada seems to be 
the one language I regularly hear good things about (which also seem 
believable AND relevant to me).

Is there any reason to use Ada as opposed to Fortran95 for my stuff
(mainly number crunching, numerical analysis etc, some home-grown 
graphics software, relatively simple text processing etc; almost all 
code I use is my own)?

What are the main advantages/disadvantages of Fortran and Ada?

How many platforms have ada compilers (in principle AND in practice)?

I just subscribed to comp.lang.ada, but have been a regular
comp.lang.fortran reader (and contributor) for years.  I notice some 
folks appear to be regulars in both newsgroups, so perhaps they could 
answer these questions or, if they're FAQs, point me to the FAQ.


--
Phillip Helbig                          Email ......... p.helbig@jb.man.ac.uk
Nuffield Radio Astronomy Laboratories   Tel. ... +44 1477 571 321 (ext. 2635)
Jodrell Bank                            Fax ................ +44 1477 571 618
Macclesfield                            Telex ................ 36149 JODREL G
UK-Cheshire SK11 9DL                    Web ... http://www.jb.man.ac.uk/~pjh/

My opinions are not necessarily those of NRAL or the University of Manchester.

Re: should I be interested in ada?

[Gautier]

> I'm actually quite happy programming in Fortran95 but Ada seems to be
> the one language I regularly hear good things about (which also seem
> believable AND relevant to me).
> 
> Is there any reason to use Ada as opposed to Fortran95 for my stuff
> (mainly number crunching, numerical analysis etc, some home-grown
> graphics software, relatively simple text processing etc; almost all
> code I use is my own)?

The pluses: see below
The minus: as for every language change there are decisions to take
with the software already done:
- translate (f2a perl script does the most)
- interface when it would take too long to translate - see example as P.S.

In terms of time, in my own project, the minus has costed me a week,
the pluses have saved me about 6 months. So far I didn't need a
debugger! It lets me plenty of time to read and answer the news 8-� !

> What are the main advantages/disadvantages of Fortran and Ada?

Ada has been conceived with the experience of mistakes done with old
languages (Fortran, C,...) and by clever people.

You'll enjoy, among others:

- readibility
- well-done variable visibility: important for large numerics programs
- strong typing which allows to catch plenty of mistakes
- bounds of arrays always obtainable (that can be save plenty of hairs
  nerves, keyboards in usual Fortran programming life)
- exceptions: replaces complicated Fortran error management codes
  useful when a 0 determinant should result as an error in a context
  and not in another (see P.S., "raise" statements)
- modularity
- portability

The combination of the 2 latter allows me to use the same source file
containing a Finite Element library for my calculations under OpenVMS (DEC Ada)
and for the graphics program on PC (GNAT/DOS) to interpolate positions in
elements, for displaying results.

> How many platforms have ada compilers (in principle AND in practice)?

Just for the freeware GNAT, there are plenty!
Here is a list of the "official" ones: http://www.gnat.com/platforms.HTM

-- 
Gautier

--------
Homepage: http://www.unine.ch/math/Personnel/Assistants/Gautier/Montmollin.html
Software: http://www.unine.ch/math/Personnel/Assistants/Gautier/Gaut_FTP.htm.

PS: example of interfacing Fortran/Ada for LAPACK (perhaps could be made simpler,
    but it works...)

--------------
--- DPBTRF ---
--------------

  procedure DGBTRF_f(M,N, KL,KU: Natural;
                     AB: in out Matrix; LDAB: Positive; IPIV: out IVector;
                     INFO: out Integer);

  PRAGMA Interface (FORTRAN, DGBTRF_f);
  PRAGMA Import_Procedure(Dgbtrf_f, Dgbtrf,
  Parameter_Types => (Natural,Natural,Natural,Natural,
                      Matrix,Positive,IVector,Integer),
  Mechanism => (Reference,Reference,Reference,Reference,
                Reference,Reference,Reference,Reference));

  procedure DGBTRF(M,N, KL,KU: Natural;
                   AB: in out Matrix; LDAB: Positive; IPIV: out IVector) is
    begin
      DGBTRF_f(M,N,KL,KU,AB,LDAB,IPIV,INFO);
      if INFO<0 then raise Illegal_value;
      elsif INFO>0 then raise Computation_error;
      end if;
    end;

Re: should I be interested in ada?

[Marin David Condic]

Phillip Helbig wrote:
> Is there any reason to use Ada as opposed to Fortran95 for my stuff
> (mainly number crunching, numerical analysis etc, some home-grown
> graphics software, relatively simple text processing etc; almost all
> code I use is my own)?
> 
It's been quite a while since I've used Fortran and I'm not familiar
with the latest iteration of the language, so I couldn't provide you
with any sort of reasonable comparison. But what I can do is point out
that Ada95 has excellent numeric capabilities in its own right.

Ada gives you the ability to precisely specify the accuracy required for
numeric types and gets very explicit about he semantics of the numeric
operations. So if your calculations are sensitive to these issues, you
stand a pretty good chance of conducting analysis and getting what you
need from the compiler. There are also a number of numeric packages
(vectors, matrices, etc.) available in Ada for the cost of some net
surfing and a download. (A good place to start looking is:
www.adahome.com Most of us are willing to cough up our bookmarks if you
have something specific in mind.) 

Ada also provides mechanisims for connecting to Fortran coded
subroutines so you can make use of whatever code you already have. The
GNAT compiler for Ada supports the interfaces to other languages and
there is a Fortran compiler (somewhere) based on the underlying gcc
compiler, so there should be no problem connecting up code if this is
what you base your environment on. (Sidebar: It would sure be nice to
see the variety of "front ends" for gcc combined in such a way that it
would be easy to have Ada, C, C++, Fortran and ??? all in the same
installation. I found the gcc-based Fortran compiler available
somewhere, but then did not attempt to install it for fear of messing up
my GNAT installation in some manner.)

Ada is a good general purpose language with a variety of add-on software
libraries available, so it would support just about any programming
requirements you might have. I can't say if you would be better off
switching to Ada95 - only you know what your precise needs are. But I
can say that there is no reason you would *not* be able to do numerical
programming if you chose Ada95 and there are many advantages to going
this route.

MDC
-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
Ph: 561.796.8997         Fx: 561.796.4669
***To reply, remove "bogon" from the domain name.***

    "Crime does not pay ... as well as politics."

        --  A. E. Newman

Re: should I be interested in ada?

[David Starner]

Marin David Condic wrote:
> Sidebar: It would sure be nice to
> see the variety of "front ends" for gcc combined in such a way that it
> would be easy to have Ada, C, C++, Fortran and ??? all in the same
> installation. I found the gcc-based Fortran compiler available
> somewhere, but then did not attempt to install it for fear of messing up
> my GNAT installation in some manner.)

See egcs.cygnus.com. The EGCS compiler has most of the compiler
frontends in one package. Unfortunetly, there have been some
improvements from the GCC sources, and a front end that will compile
against GCC 2.8.1 won't compile against EGCS. For example, GNAT won't
compile with it. Since ACT isn't intrested, and Cygnus isn't interested
enough to pull people to work on it, the nesseccary patches to GNAT
aren't forthcoming. My advice is to compile EGCS into /usr/local/egcs
and then simlink to /usr/local/ using names like egcc or whatever. The
frontends that come with EGCS are C, C++, Objective C, and Fortran.
Pascal will compile against it, too, if you get the package from
elsewhere. 

-- 
The irony is, there ARE drugs that ENHANCE it. This says something
profound about either science or medicine or people or muppets or all
four. - S. John Ross

Re: should I be interested in ada?

[Ken Thomas]

Phillip Helbig wrote:
> 
> I'm actually quite happy programming in Fortran95 but Ada seems to be
> the one language I regularly hear good things about (which also seem
> believable AND relevant to me).
> 
> Is there any reason to use Ada as opposed to Fortran95 for my stuff
> (mainly number crunching, numerical analysis etc, some home-grown
> graphics software, relatively simple text processing etc; almost all
> code I use is my own)?
> 
> What are the main advantages/disadvantages of Fortran and Ada?
> 
> How many platforms have ada compilers (in principle AND in practice)?
> 
> I just subscribed to comp.lang.ada, but have been a regular
> comp.lang.fortran reader (and contributor) for years.  I notice some
> folks appear to be regulars in both newsgroups, so perhaps they could
> answer these questions or, if they're FAQs, point me to the FAQ.
> 

The advantage of multilanguage programming cannot be dismissed. The
ability to get at BLAS is essential if speed is required. I have done a
few tests on the SP2 using GNAT3.11 (options -gnatp -O3)

	Level 1	(daxpy)	Ada 17Mflops	ESSL	60
	Level 2  (gemv)	Ada 12Mflops	ESSL	140

I have not done level 3 at the moment.

There is a binding to LAPACK on the gnat distribution site.

Ken


-- 
Dr K.S. Thomas
Department of Electronics and Computer Science
University of Southampton
Highfield
Southampton SO17 1BJ
United Kingdom

Telephone : (+44) 01703 592170
Fax :       (+44) 01703 593903

email: kst@ecs.soton.ac.uk

Re: should I be interested in ada?

[Nick Roberts]

Phil,

(You may be aware) there is a Fortran project (Austrian I think) at the
moment which can automatically parallelise Fortran programs. I don't have
the URL, but I'm sure someone in comp.lang.fortran will oblige you. Most
Fortran 90 syntax is supported, I think.

There's no reason this couldn't be done for Ada, in theory, but in practice
I don't think it'll happen. From a speed point of view, this ability could
be of overriding importance.

I'm not au fait with the nitty gritty of this project, however.

Other than this, there's nothing Fortran can do that Ada cannot, and quite a
few things that Ada can do better. It may be, in practice, that sometimes
Fortran compilers can/will produce faster object code, but I think this is,
in every case (or almost), only a matter of practice, rather than a
theoretical limit.

-------------------------------------
Nick Roberts
-------------------------------------

Re: should I be interested in ada?

[robert_dewar]

In article <7afc1o$3mi$2@plug.news.pipex.net>,
  "Nick Roberts" <Nick.Roberts@dial.pipex.com> wrote:
> Phil,
>
> (You may be aware) there is a Fortran project (Austrian I
> think) at the moment which can automatically parallelise
> Fortran programs. I don't have the URL, but I'm sure
> someone in comp.lang.fortran will oblige you. Most
> Fortran 90 syntax is supported, I think.

What a bizarre pointer. There are dozens of such
"projects", and indeed modern Fortran compilers are
expected to do this kind of parallelization, i.e. this
has gone far beyond the research project level, and is
considered standard state of the art in commercial Fortran
compilers.


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

Re: should I be interested in ada?

[Nick Roberts]

robert_dewar@my-dejanews.com wrote in message
<7aftp7$7u5$1@nnrp1.dejanews.com>...
|In article <7afc1o$3mi$2@plug.news.pipex.net>,
|  "Nick Roberts" <Nick.Roberts@dial.pipex.com> wrote:
|> Phil,
|>
|> (You may be aware) there is a Fortran project (Austrian I
|> think) at the moment which can automatically parallelise
|> Fortran programs. I don't have the URL, but I'm sure
|> someone in comp.lang.fortran will oblige you. Most
|> Fortran 90 syntax is supported, I think.
|
|What a bizarre pointer. There are dozens of such
|"projects", and indeed modern Fortran compilers are
|expected to do this kind of parallelization, i.e. this
|has gone far beyond the research project level, and is
|considered standard state of the art in commercial Fortran
|compilers.


Surely this is a wee bit of an exaggeration? The majority of targets for
Fortran compilers are single-processor. I would be amazed if the majority of
Fortran compilers available today, commercially or not, were parallelising.
I am aware that there are a number of Fortran compilers which parallelise,
and have been for many years, but all but one, I believe, only do it for a
specific, fairly esoteric target (Crays etc.), thus not being likely, I
assume, to be useful to astrologers in general.

If my memory serves me, the compiler I am referring to parallelises to a set
of Fortran programs which communicate with one another using a standard RPC
mechanism, thus making it potentially suitable for use on a cluster or
network of VAXen or workstations. This project is an international
collaboration, so it may appear that there are dozens of compilers which are
all, in fact, the same one (or variants thereof).

I was not trying to make a statement on the current state-of-the-art in
Fortran compilers, I was trying to give some information that might be
useful to the original poster (an astrologer). I did mention in my post that
my knowledge of this particular project was limited, and I reiterate it.
Indeed, I do not claim to be an expert on this subject, in general. In any
event, I will try to find the URL.

I hope my comments on comp.lang.ada are not considered unwelcome; it is not
my intention to mislead anyone.

-------------------------------------
Nick Roberts
-------------------------------------

Re: should I be interested in ada?

[William Clodius]

Nick Roberts wrote:
> <snip>
> Surely this is a wee bit of an exaggeration? The majority of targets for
> Fortran compilers are single-processor. I would be amazed if the majority of
> Fortran compilers available today, commercially or not, were parallelising.
> I am aware that there are a number of Fortran compilers which parallelise,
> and have been for many years, but all but one, I believe, only do it for a
> specific, fairly esoteric target (Crays etc.), thus not being likely, I
> assume, to be useful to astrologers in general.
> <snip>

There are roughly four groups of Fortran compiler "vendors":

1. Those sold by the system vendors: IBM, Sun, Compaq/DEC, SGI/Cray, HP,
Fujitsu, etc. These sell both single processor and multiprocessor
systems. While most of the systems sold are single or dual processor,
they always have multiprocessor compilation options for their compilers,
otherwise they couldn't sell their high end systems.

2. Independent vendors that address a large variety of systems: e.g.,
EPC, Portland group, Pacific-Sierra, and NAG. These often also go after
the high end, which means parallelization options.

3. Independent vendors that target the low end of the market, e.g.,
Lahey, Absoft, and Salford. In the past these have not had
parallelization options, but with the popuarity of dual processor, and
networked processors they are implementing them.

4. Academics that have often focused on parallelization.

A lot of the focus on Fortran parallelization has been on HPF (High
performance Fortran). Most implementors of these compilers have
parallelization features.

http://www.crpc.rice.edu/HPFF/compilers/index.html

-- 

William B. Clodius		Phone: (505)-665-9370
Los Alamos Nat. Lab., NIS-2     FAX: (505)-667-3815
PO Box 1663, MS-C323    	Group office: (505)-667-5776
Los Alamos, NM 87545            Email: wclodius@lanl.gov

Re: should I be interested in ada?

[dennison]

In article <36CC3761.15FB@lanl.gov>,
  William Clodius <wclodius@lanl.gov> wrote:

> A lot of the focus on Fortran parallelization has been on HPF (High
> performance Fortran). Most implementors of these compilers have
> parallelization features.

...and HPF *does* have things that would be tough to do in vanilla Ada, eg:
the three kinds of parallel loops.

T.E.D.

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

Re: should I be interested in ada?

[robert_dewar]

In article <7afc1o$3mi$2@plug.news.pipex.net>,
  "Nick Roberts" <Nick.Roberts@dial.pipex.com> wrote:
> Other than this, there's nothing Fortran can do that Ada
> cannot, and quite a few things that Ada can do better. It
> may be, in practice, that sometimes Fortran compilers
> can/will produce faster object code, but I think this is,
> in every case (or almost), only a matter of practice,
> rather than a theoretical limit.

I find it hard to believe that Nick knows Fortran-90 if
he writes such a claim.

Yes of course all languages are Turing complete, so of
course you can do anything in any language, but Fortran-90
has many features not present in Ada. To give just one
example, it has a much more sophisticated mechanism for
dealing with array aggregates and array aggregate
operations.

It does not help Ada 95 to make bogus claims about it based
on lack of knowledge of languages to which you are
comparing it. After all people are always doing this to
Ada, don't make the same mistake!

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

Re: should I be interested in ada?

[Nick Roberts]

robert_dewar@my-dejanews.com wrote in message
<7afttr$7v3$1@nnrp1.dejanews.com>...
|In article <7afc1o$3mi$2@plug.news.pipex.net>,
|  "Nick Roberts" <Nick.Roberts@dial.pipex.com> wrote:
|> Other than this, there's nothing Fortran can do that Ada
|> cannot, and quite a few things that Ada can do better. It
|> may be, in practice, that sometimes Fortran compilers
|> can/will produce faster object code, but I think this is,
|> in every case (or almost), only a matter of practice,
|> rather than a theoretical limit.
|
|Yes of course all languages are Turing complete, so of
|course you can do anything in any language, but Fortran-90
|has many features not present in Ada. To give just one
|example, it has a much more sophisticated mechanism for
|dealing with array aggregates and array aggregate
|operations.


Maybe I could have phrased it a little more clearly. I meant there's nothing
Fortran can do that Ada cannot also do reasonably easily. Certainly, Fortran
has some convenience notations that are not so convenient in Ada. To take
Fortran's array facilities as an example, in Fortran one can put:

   real, dimension (1:10) :: x
   ...
   x = 1.0

setting all the elements of x to 1.0 (a 'broadcast scalar'), whereas in Ada
to do the same thing, you must code something like:

   X: array (1..10) of Float;
   ...
   for i in X'Range loop X(i) := 1.0; end loop;

or define a utility procedure, e.g.:

   type Vector is array (Integer range <>) of Float;
   ...
   X: Vector(1..10);
   ...
   procedure Fill (Object: in out Vector; Value: in Float) is
   begin
      for i in Object'Range loop
         Object(i) := Value;
      end loop;
   end;

and then one can simply call:

   Fill(X,1.0);

Fortran provides the handy 'where' statement, e.g.:

   where (x /= 0.0) x = 1.0/x

reciprocates all the elements of x except those which are zero. The
equivalent in Ada might be:

   for i in X'Range loop
      if X(i) /= 0.0 then X(i) := 1.0/X(i); end if;
   end loop;

Or again, defining a procedure:

   procedure Reciprocate(V: Vector) is
   begin
      for i in V'Range loop
         if V(i) /= 0.0 then V(i) := 1.0/V(i); end if;
      end loop;
   end;

and then the call:

   Reciprocate(X);

will do the trick. And so on.

I think it's probably best to leave the reader to decide whether the Ada
equivalents I have demonstrated here are likely to be an onerous burden to
the programmer or not. I believe Jean Ichbiah (leader of the team that
designed 'Green', the language that became Ada 83) once said "Ada is a very
simple language". Personally, I think Ada strikes a good balance of
sophistication where it is needed, but simplicity where it is not.

|I find it hard to believe that Nick knows Fortran-90 if
|he writes such a claim.

I'm afraid I must say that this strikes me as being a slightly
unprofessional comment. May I suggest that comments as to the lack of
knowledgeability of fellow usenet users are best made with a little greater
caution?

|It does not help Ada 95 to make bogus claims about it based
|on lack of knowledge of languages to which you are
|comparing it. After all people are always doing this to
|Ada, don't make the same mistake!

Certainly true. I will endeavour not to make bogus claims, and hope that
others will make a similar effort.


-------------------------------------
Nick Roberts

'The time has come,' the Walrus said,
  'To talk of many things:
Of shoes--of ships--and sealing wax--
  Of cabbages--and kings--
And why the sea is boiling hot--
  And whether pigs have wings.'
                        Lewis Carroll
          "Through the Looking Glass"
-------------------------------------

Re: should I be interested in ada?

[robert_dewar]

In article <7aganu$qsc$1@plug.news.pipex.net>,

> |I find it hard to believe that Nick knows Fortran-90 if
> |he writes such a claim.
>
> I'm afraid I must say that this strikes me as being a
> slightly unprofessional comment. May I suggest that
> comments as to the lack of knowledgeability of fellow
> usenet users are best made with a little greater
> caution?

Well I would say your examples still don't show anything
like the power of the aggregate facilities in Fortran which
far outstrip Ada's. If you know Fortran-90, then you know
that you can construct examples where the Fortran-90 code
is very nice, and the corresponding Ada, especially where
multi-dimensional arrays are involved, is very low level
and tortured.

Your set of examples seem to have been carefully
constructed to make the best case for Ada, but any Fortran
programmer will be able to demolish such arguments with
much more powerful examples.


> |It does not help Ada 95 to make bogus claims about it
> |on lack of knowledge of languages to which you are
> |comparing it. After all people are always doing this to
> |Ada, don't make the same mistake!
>
> Certainly true. I will endeavour not to make bogus
> claims, and hope that others will make a similar effort.

All I can say Nick, is that if you really DO know
Fortran-90 well, then you really are choosing examples
in a biased and unfair manner. I don't think this helps
Ada. I actually think my viewpoint that this must be from
lack of practical experience with Fortran-90 was a more
positive view. If you are really an experienced Fortran-90
programmer, then you should really not be making the claims
that you making!



>
> -------------------------------------
> Nick Roberts
>
> 'The time has come,' the Walrus said,
>   'To talk of many things:
> Of shoes--of ships--and sealing wax--
>   Of cabbages--and kings--
> And why the sea is boiling hot--
>   And whether pigs have wings.'
>                         Lewis Carroll
>           "Through the Looking Glass"
> -------------------------------------
>
>

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

Re: should I be interested in ada?

[Nick Roberts]

Perhaps you would care to produce some 'powerful examples' yourself?

Bear in mind, my original claim was that "there is nothing that can be done
in Fortran that cannot be done in Ada." I didn't say "that cannot be done
just as neatly" and I didn't mean it. I just meant "that cannot also be done
_reasonably easily_ in Ada."

I chose simple examples so as to keep the examples simple, and they are very
realistic; examination of typical Fortran programs shows this. I am not an
_experienced_ Fortran 90 programmer, and never claimed to be.

-------------------------------------
Nick Roberts
-------------------------------------

Re: should I be interested in ada?

[robert_dewar]

In article <7aingo$orv$2@plug.news.pipex.net>,
  "Nick Roberts" <Nick.Roberts@dial.pipex.com> wrote:
> Perhaps you would care to produce some 'powerful
examples' yourself?
>
> Bear in mind, my original claim was that "there is
> nothing that can be done in Fortran that cannot be done
> in Ada." I didn't say "that cannot be done just as
> neatly" and I didn't mean it. I just meant "that cannot
> also be done _reasonably easily_ in Ada."

Obvious example; a parallel loop with no implied ordering
in the sequence. We once extensively discussed the
following addition to Ada:

   for all J in ... loop ...

with that meaning. Without an extension, there is simply
no "reasonably easy" way to program this in Ada.

(actually I am not sure if Fortran-90 has this extension,
but it is certainly in HPF, and really these days you have
to be talking about both if you are talking state of the
art Fortran).

Doesn't Fortran also have slicing of multi-dimensional
arrays, this is also obviously very painful in Ada.

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

Re: should I be interested in ada?

[William Clodius]

robert_dewar@my-dejanews.com wrote:
> <snip>
> Obvious example; a parallel loop with no implied ordering
> in the sequence. We once extensively discussed the
> following addition to Ada:
> 
>    for all J in ... loop ...
> 
> with that meaning. Without an extension, there is simply
> no "reasonably easy" way to program this in Ada.
> 
> (actually I am not sure if Fortran-90 has this extension,
> but it is certainly in HPF, and really these days you have
> to be talking about both if you are talking state of the
> art Fortran).
> 
> Doesn't Fortran also have slicing of multi-dimensional
> arrays, this is also obviously very painful in Ada.
> <snip>

The current standard is Fortran 95 (accepted as a standard in 1997)
which adopted FORALL from HPF. It was also one of many proposals for
Fortran 8x that was discarded in the attempt to have a complete standard
by 1988. There are many possible forms of array slices, the more complex
forms rely on FORALL or WHERE on a per statement basis. Simple ones can
be done with variables with Fortran's "POINTER" attribute, with
procedure or module scope, or by a simple array notation on a per
statement basis.

Note the HPF directives have not been adopted by the Fortran standard.

-- 

William B. Clodius		Phone: (505)-665-9370
Los Alamos Nat. Lab., NIS-2     FAX: (505)-667-3815
PO Box 1663, MS-C323    	Group office: (505)-667-5776
Los Alamos, NM 87545            Email: wclodius@lanl.gov

Re: should I be interested in ada?

[Nick Roberts]

robert_dewar@my-dejanews.com wrote in message
<7ajl7i$e8v$1@nnrp1.dejanews.com>...
|In article <7aingo$orv$2@plug.news.pipex.net>,
|  "Nick Roberts" <Nick.Roberts@dial.pipex.com> wrote:
|> Perhaps you would care to produce some 'powerful
|examples' yourself?
|>
|> Bear in mind, my original claim was that "there is
|> nothing that can be done in Fortran that cannot be done
|> in Ada." I didn't say "that cannot be done just as
|> neatly" and I didn't mean it. I just meant "that cannot
|> also be done _reasonably easily_ in Ada."
|
|Obvious example; a parallel loop with no implied ordering
|in the sequence. We once extensively discussed the
|following addition to Ada:
|
|   for all J in ... loop ...
|
|with that meaning. Without an extension, there is simply
|no "reasonably easy" way to program this in Ada.


In fact, there is always a very easy way to program this in Ada. I have
given an example, in another post, of an Ada equivalent of a Fortran FORALL
statement. If anyone would care to provide an example of a Fortran parallel
loop, I will demonstrate how easy it is to reprogram it in Ada.

[...]
|Doesn't Fortran also have slicing of multi-dimensional
|arrays, this is also obviously very painful in Ada.


Yes, and yes it is fairly painful, but far from impractical. I've given an
example in another post, where one Fortran line becomes seven Ada lines. I
reckon this is an extreme example, in practical terms. And, even so, in
terms of programmer productivity and debugging effort, I would contend that
the effective cost of these different forms would be the same: it's not
going to take a programmer a significantly extra amount of time just to type
in the extra text; the bulkier form is not going to be likely to give rise
to more bugs, or to be more difficult to debug if it does.

-------------------------------------
Nick Roberts
-------------------------------------

Re: should I be interested in ada?

[robert_dewar]

In article <7akvap$j5t$3@plug.news.pipex.net>,
  "Nick Roberts" <Nick.Roberts@dial.pipex.com> wrote:
> In fact, there is always a very easy way to program this
> in Ada. I have given an example, in another post, of an
> Ada equivalent of a Fortran FORALL statement.

I have seen no such example, perhaps my newsreader
(dejanews) lost a post. Nor do I think a reasonable
equivalence is possible (you might want to dig up the
ancient and extended thread on implementing for all in
Ada 95).

> If anyone would care to provide an example of a Fortran
> parallel loop

You know Fortran, make your own example!

> [...]
> |Doesn't Fortran also have slicing of multi-dimensional
> |arrays, this is also obviously very painful in Ada.



> Yes, and yes it is fairly painful, but far from
> impractical. I've given an
> example in another post, where one Fortran line becomes
> seven Ada lines. I reckon this is an extreme example, in
> practical terms. And, even so, in terms of programmer
> productivity and debugging effort, I would contend that
> the effective cost of these different forms would be the
> same: it's not going to take a programmer a significantly
> extra amount of time just to type in the extra text; the
> bulkier form is not going to be likely to give rise
> to more bugs, or to be more difficult to debug if it
> does.

All these are dubious claims in the extreme. All available
data indicates that number of lines of code is an important
indicator, and most certainly the debugging effort is much
greater. I am beginning to wonder how much Fortran you have
actually written (i.e. Fortran code using these kind of
slicing semantics). I actually have not written much, but
I have written lots of Algol-68 code using multiple
dimensional array slicing, for linear algebra applications,
and that kind of code is FAR harder to write in Ada, no
doubt about it.

Of course it would be surprising if we could not find some
examples where it is easier to write X in Y than in Z, for
some X and all Y and Z. For example, the silly thread
recently where X was "sorting using only standard language
features", Y was C++ and Z was Ada 95.

This does not mean that Y is necesarily better than Z, even
for programs that involve X, since there may be other
advantages that outweigh the very specific comparison
point.

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

Re: should I be interested in ada?

[Steve Doiel]

In response to the original question... Should I be interested in Ada?

Yes.

My response is the same if you ask about Ada, C++, Java, etc.

While you may come back to using FORTRAN, I have always found
learning other languages to be worthwhile.

SteveD

Re: should I be interested in ada?

[robert_dewar]

Actually Nick, you are doing pretty well today. You have
solved the halting problem (by determining that aliasing
analysis is equivalent to Fortran's anti-aliasing rules).
You have shown that productivity is independent of the
number of lines of code, and that furthermore it is just
as easy to debug a long low level program as a short high
level one, and consequently as a corollory completely
debunked the notion that high level features are useful
in programming languages :-)


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

Re: should I be interested in ada?

[dennison]

In article <7alcqe$v7g$1@nnrp1.dejanews.com>,
  robert_dewar@my-dejanews.com wrote:
> Actually Nick, you are doing pretty well today. You have
> solved the halting problem (by determining that aliasing
...

My 3yr. old tells me that to put out the flames you should "stop, drop, and
roll", Nick. :-)


T.E.D.

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

Re: should I be interested in ada?

[Nick Roberts]

I always try to do at least three impossible things before breakfast :-)

-------------------------------------
Nick Roberts
-------------------------------------

robert_dewar@my-dejanews.com wrote in message
<7alcqe$v7g$1@nnrp1.dejanews.com>...
|Actually Nick, you are doing pretty well today. You have
|solved the halting problem (by determining that aliasing
|analysis is equivalent to Fortran's anti-aliasing rules).
|You have shown that productivity is independent of the
|number of lines of code, and that furthermore it is just
|as easy to debug a long low level program as a short high
|level one, and consequently as a corollory completely
|debunked the notion that high level features are useful
|in programming languages :-)

Re: should I be interested in ada?

[Robert I. Eachus]

In article <7aslft$gpq$4@plug.news.pipex.net> "Nick Roberts" <Nick.Roberts@dial.pipex.com> writes:

  > I always try to do at least three impossible things before breakfast :-)

   Six!  You have to do six or you will fall behind. ;-)

   Anyone completely lost should get Through the Looking Glass by
Lewis Carroll and read the first encounter between Alice and the Red
Queen.  And if you haven't read both Alice books as an adult, get them
and read them!  You will find that they were not really written for
children, and you have to be a pretty sophisticated logician to get
some of the jokes.  (Charles Dodgson also wrote a book on Boolean
Logic which was still used as a college text when I was growing up.)


--

					Robert I. Eachus

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

White rabbit (was: should I be interested in ada?)

[dennison]

In article <EACHUS.99Feb23183152@spectre.mitre.org>,
  eachus@spectre.mitre.org (Robert I. Eachus) wrote:

> Queen.  And if you haven't read both Alice books as an adult, get them
> and read them!  You will find that they were not really written for
> children, and you have to be a pretty sophisticated logician to get
> some of the jokes.  (Charles Dodgson also wrote a book on Boolean
> Logic which was still used as a college text when I was growing up.)

My graduate Algorithm Analysis textbook had an illustration from one of the
"Alice" books on the front cover. Apparently Dodgson also did an analysis for
the Wimbleton tennis club of the proper algorithm to ensure that the best two
canidates meet in the finals of a tournament. Not only is the algorithm
somewhat useful for computer scientists, but his analysis led directly to the
seeding system used in Tennis and many other sports today.

T.E.D.

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

Alice books (was: should I be interested in ada?)

[JP Thornley]

In article: <EACHUS.99Feb23183152@spectre.mitre.org>  
eachus@spectre.mitre.org (Robert I. Eachus) writes:
> And if you haven't read both Alice books as an adult, get them
> and read them!  You will find that they were not really written for
> children, and you have to be a pretty sophisticated logician to get
> some of the jokes.

Even better, if you can find it, get hold of Martin Gardner's Annotated 
Alice book*. It explains lots of those jokes, and includes a detailed 
description of the chess moves in the Looking Glass story.

Phil Thornley

*My copy is published by Penguin, so would not have been available in 
the US. But it says: "First published in the U.S.A by Clarkson N. Potter 
Inc. 1960"

-- 
------------------------------------------------------------------------
| JP Thornley    EMail jpt@diphi.demon.co.uk                           |
|                      phil.thornley@acm.org                           |
------------------------------------------------------------------------

Re: Alice books (was: should I be interested in ada?)

[Robert I. Eachus]

In article <645343458wnr@diphi.demon.co.uk> jpt@diphi.demon.co.uk (JP Thornley) writes:

  > Even better, if you can find it, get hold of Martin Gardner's Annotated 
  > Alice book*. It explains lots of those jokes, and includes a detailed 
  > description of the chess moves in the Looking Glass story.

  I have it, but my copy is a first edition, so I don't know if it is
still available, but it should be!  (My favorite is the German version
of Jabberwocky: "Es brillig war, und die schlichte toven,...")

--

					Robert I. Eachus

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

Re: should I be interested in ada?

[Phillip Helbig]

In article <7ajl7i$e8v$1@nnrp1.dejanews.com>,
robert_dewar@my-dejanews.com writes: 

> Obvious example; a parallel loop with no implied ordering
> in the sequence. We once extensively discussed the

> no "reasonably easy" way to program this in Ada.
> 
> (actually I am not sure if Fortran-90 has this extension,
> but it is certainly in HPF, and really these days you have
> to be talking about both if you are talking state of the
> art Fortran).

F95 has the FORALL statement and construct (yes, inspired by HPF).

> Doesn't Fortran also have slicing of multi-dimensional
> arrays, this is also obviously very painful in Ada.

Yes, it does.


--
Phillip Helbig                          Email ......... p.helbig@jb.man.ac.uk
Nuffield Radio Astronomy Laboratories   Tel. ... +44 1477 571 321 (ext. 2635)
Jodrell Bank                            Fax ................ +44 1477 571 618
Macclesfield                            Telex ................ 36149 JODREL G
UK-Cheshire SK11 9DL                    Web ... http://www.jb.man.ac.uk/~pjh/

My opinions are not necessarily those of NRAL or the University of Manchester.

Re: should I be interested in ada?

[dennison]

In article <7ajl7i$e8v$1@nnrp1.dejanews.com>,
  robert_dewar@my-dejanews.com wrote:
> In article <7aingo$orv$2@plug.news.pipex.net>,

> Obvious example; a parallel loop with no implied ordering
> in the sequence. We once extensively discussed the
> following addition to Ada:
>
>    for all J in ... loop ...
>
> with that meaning. Without an extension, there is simply
> no "reasonably easy" way to program this in Ada.

Since Fortran's parallel loops are just loops with extra semantics about what
dependencies exist between iterations, wouldn't it be possible to do the same
thing in Ada with new loop pragmas? (eg: prama No_Loop_Carried_Dependencies
(Loop_Label);) Would such a scheme render the compiler non-conformant?

T.E.D.

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

Re: should I be interested in ada?

[William Clodius]

dennison@telepath.com wrote:
> <snip>
> Since Fortran's parallel loops are just loops with extra semantics about what
> dependencies exist between iterations, wouldn't it be possible to do the same
> thing in Ada with new loop pragmas? (eg: prama No_Loop_Carried_Dependencies
> (Loop_Label);) Would such a scheme render the compiler non-conformant?
> <snip>

In essence yes.  The parallel loop forms introduce a context in which,
for example, all input values are those of the variables at the start of
the loop. A variable used as input may in turn depend on the loop, but
that dependence must be treatable as an assignment to a temporary which
is then reassigned to the variable at the end of the loop. This of
course means that a given array element must be modified at most once in
leagal code, but that is not the same as saying it isn't modified at
all, which is what is implied by No_Loop_Carried_Dependencies.
Dependencies are allowed but treated specially.

-- 

William B. Clodius		Phone: (505)-665-9370
Los Alamos Nat. Lab., NIS-2     FAX: (505)-667-3815
PO Box 1663, MS-C323    	Group office: (505)-667-5776
Los Alamos, NM 87545            Email: wclodius@lanl.gov

Re: should I be interested in ada?

[robert_dewar]

In article <7ajv17$mrf$1@nnrp1.dejanews.com>,
  dennison@telepath.com wrote:
> Since Fortran's parallel loops are just loops with extra
> semantics about what dependencies exist between
> iterations, wouldn't it be possible to do the same thing
> in Ada with new loop pragmas? (eg: prama
> No_Loop_Carried_Dependencies (Loop_Label);) Would such a
> scheme render the compiler non-conformant?


Well you can always make arbitrary extensions by using the
fiction that they are pragmas, and this particular form of
the pragma is in fact quite a respectable one, but it is
not what I would choose, I would prefer to have a clear
statement that the branches can be done in parallel, not
some rather peculiar statement with unfamiliar terminology
from which this can be deduced!

As for non-conformance, you can simply implement

   for all K in ... loop

and that is still no problem as long as its recognition is
controlled by a switch, e.g. something like --pedantic in
GNU C. So there is never an issue with conformance in
such extensions.

Actually implementation defined pragmas are a rather
pernicious form of language extension, that leaves ISO
Ada even more susceptible to uncontrolled extension than
in COBOL. In COBOL, you have to have a flag that restricts
implementation defined extensions, but there is no such
requirement for Ada with respect to pragmas.

GNAT has added the Restrictions identifiers:

   pragma Restrictions (No_Implementation_Pragmas);
   pragma Restrictions (No_Implementation_Attributes);

but unfortunately these identifiers are themselves
implementation defined. It would be nice if every compiler
would at least adopt these two restriction identifiers.

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

Re: should I be interested in ada?

[Nick Roberts]

dennison@telepath.com wrote in message <7ajv17$mrf$1@nnrp1.dejanews.com>...
[...]
|Since Fortran's parallel loops are just loops with extra semantics about
what
|dependencies exist between iterations, wouldn't it be possible to do the
same
|thing in Ada with new loop pragmas? (eg: prama No_Loop_Carried_Dependencies
|(Loop_Label);) Would such a scheme render the compiler non-conformant?


I don't think there would be any point. In nearly all practical cases, an
optimiser can determine if the order of iteration of the loop doesn't
matter; it can then do vectorisation or parallelisation perfectly well.
(And, in many cases, the optimiser can be helped simply by rearranging the
algorithm a little.)

-------------------------------------
Nick Roberts
-------------------------------------

Re: should I be interested in ada?

[robert_dewar]

In article <7akvaq$j5t$4@plug.news.pipex.net>,
  "Nick Roberts" <Nick.Roberts@dial.pipex.com> wrote:
>
> I don't think there would be any point. In nearly all
> practical cases, an optimiser can determine if the order
> of iteration of the loop doesn't matter; it can then do
> vectorisation or parallelisation perfectly well.
> (And, in many cases, the optimiser can be helped simply
> by rearranging the algorithm a little.)

So I guess you are saying Nick that the folks who designed
Fortran 95 did not know what they were doing, and that the
parallel loop is a silly unnecessary construct :-)

I really think you should read through the old thread on
for all if it can still be found somewhere. There are a lot
of subtleties here that have occupied the minds and
research programs of a lot of top people in the compiler
field, and you really should read the literature in this
area before making pronouncements like the one above!

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

Re: should I be interested in ada?

[Nick Roberts]

robert_dewar@my-dejanews.com wrote in message
<7aldl5$p$1@nnrp1.dejanews.com>...
[...]
|I really think you should read through the old thread on
|for all if it can still be found somewhere. There are a lot
|of subtleties here that have occupied the minds and
|research programs of a lot of top people in the compiler
|field, and you really should read the literature in this
|area before making pronouncements like the one above!


More of an 'opinion' than a 'pronouncement', really! And yes, you are quite
right I should (and will forthwith).

-------------------------------------
Nick Roberts
-------------------------------------

Re: should I be interested in ada?

[William Clodius]

Be aware that easy cases of array assignements in Fortran are easilly
mapped to sequential code, but that more complex cases require
temporaries. This is particularly true of the FORALL and WHERE
constructs, and ELEMENTAL functions.

-- 

William B. Clodius		Phone: (505)-665-9370
Los Alamos Nat. Lab., NIS-2     FAX: (505)-667-3815
PO Box 1663, MS-C323    	Group office: (505)-667-5776
Los Alamos, NM 87545            Email: wclodius@lanl.gov

Re: should I be interested in ada?

[nabbasi]

In article <36CC3AEA.59E2@lanl.gov>, William says...
>
>Be aware that easy cases of array assignements in Fortran are easilly
>mapped to sequential code, but that more complex cases require
>temporaries. This is particularly true of the FORALL and WHERE
>constructs, and ELEMENTAL functions.
>
 
but could'nt all of the above be coded just as well in Ada? All
what one need is a fortran array-thingy package that implement all of
those fortran features mentioned.

It is all just code after all. may be this is another package to
add to the growing wish-list of packages for Ada that everyone 
wants, but no one has the time to do :)

nasser

Re: should I be interested in ada?

[robert_dewar]

In article <7ahi79$1rr@drn.newsguy.com>,
  nabbasi@pacbell.net wrote:
> but could'nt all of the above be coded just as well in
> Ada? All what one need is a fortran array-thingy package
> that implement all of those fortran features mentioned.

No, it couldn't, and I don't think anyone with real
practical experience in Fortran-90 would think otherwise.
There are always some things that are more convenient in
language X than in language Y. If you don't know them for
a particular X and Y, it probably just means you don't know
X and Y well enough :-)

However, the mere fact that you can display such examples
does not say anything about the general usability of X and
Y for any particular domain. Focussing on a few specific
constructs almost always gives a distorted view.
>
> It is all just code after all. may be this is another
> package to add to the growing wish-list of packages for
> Ada that everyone  wants, but no one has the time to do

Certainly a GNAT.Fortran_90 package analogous to
GNAT.Spitbol would be useful, but, as in the case of
GNAT.Spitbol, it would NOT provide the same convenience
as the native language, syntax is not completely irrelevant
:-)

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

Re: should I be interested in ada?

[robert_dewar]

In article <36CC3AEA.59E2@lanl.gov>,
  William Clodius <wclodius@lanl.gov> wrote:
> Be aware that easy cases of array assignements in Fortran
> are easilly mapped to sequential code, but that more
> complex cases require temporaries. This is particularly
> true of the FORALL and WHERE constructs, and ELEMENTAL
> functions.

William, since you obviously know this stuff well, I think
it would definitely be instructive for you to give some
examples with explanations of these constructs for the Ada
crowd, some of whom still seem confident that Ada can do
any of this stuff easily :-)

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

Re: should I be interested in ada?

[William Clodius]

Perhaps the best simple example is the FORALL statement to do a
reordering of elements

FORALL (I=1:N) X(J(I)) = X(I)

which in Ada would require the explicit creation of a temporary to hold
the value of X, assignment to the temporary, and then the assignment of
the temporary to X. Note it is required that the values of J(1:N) not
duplicate one another and lie within the dimensioned ranges of X.

-- 

William B. Clodius		Phone: (505)-665-9370
Los Alamos Nat. Lab., NIS-2     FAX: (505)-667-3815
PO Box 1663, MS-C323    	Group office: (505)-667-5776
Los Alamos, NM 87545            Email: wclodius@lanl.gov

Re: should I be interested in ada?

[Nick Roberts]

William Clodius wrote in message <36CD8DBA.237C@lanl.gov>...
|Perhaps the best simple example is the FORALL statement to do a
|reordering of elements
|
|FORALL (I=1:N) X(J(I)) = X(I)
|
|which in Ada would require the explicit creation of a temporary to hold
|the value of X, assignment to the temporary, and then the assignment of
|the temporary to X. Note it is required that the values of J(1:N) not
|duplicate one another and lie within the dimensioned ranges of X.


This is a simple example, granted. But, it can be done without undue
difficulty in Ada by declaring an appropriate procedure:

   procedure Reorder (Object: in out Vector; Index: in Selection) is
      Temp: constant Vector := Object;
   begin
      for i in Index'Range loop
         Object(Index(i)) := Temp(i);
      end loop;
   end;

and perhaps adding:

   pragma Inline(Reorder);

and then making the call:

   Reorder(X,J);

You've got to declare a utility procedure, certainly, but otherwise this is
just as neat as the Fortran, surely? More so, perhaps? And it will not
necessarily produce object code which is any less efficient than the Fortran
equivalent.

The basic principle is that there is no Fortran 90 construct which cannot be
modelled, perfectly adequately, by an Ada abstraction (typically a procedure
or function). Furthermore, you get something extra in making that
abstraction: encapsulation (factoring out common code), and a degree of
self-documentation (the name of the subprogram says what it does).

-------------------------------------
Nick Roberts
-------------------------------------

Re: should I be interested in ada?

[robert_dewar]

In article <7akvao$j5t$2@plug.news.pipex.net>,
  "Nick Roberts" <Nick.Roberts@dial.pipex.com> wrote:

>    Reorder(X,J)

>
> You've got to declare a utility procedure, certainly, but
> otherwise this is just as neat as the Fortran, surely?

My goodness one would almost think that Nick was trying to
make Ada look bad by making dubious arguments. First, the
Ada code is far uglier and less safe than the Fortran code,
I really cannot imagine anyone thinking otherwise. But
more importantly, the Ada code does not catch the semantics
of the FORALL at all, there is no parallelism at all in the
Ada code, and indeed it is quite likely that not even a
clever optimizer can bail this out, because, as always it
is the exceptions that get you in Ada (if an exception is
raised, the semantics dictate exactly which iterations of
the loop have occured and which have not). Nick has
conveniently ignored this in his thinking, but it turns
out to be absolutely crucial. All sorts of loops in Fortran
that can be assumed to be parallel by the optimizer even if
FORALL is not used CANNOT be assumed to be parallel in Ada
because of the exception issue.

This means that FOR ALL is in a sense even more crucial
in Ada (which doesn't have it) than in Fortran 95 (which
does).

All this was covered in rather excruciating detail in the
thread a few years ago about implementing FOR ALL in Ada.



 More so, perhaps? And it will not
> necessarily produce object code which is any less

efficient than the Fortran
> equivalent.
>
> The basic principle is that there is no Fortran 90

construct which cannot be
> modelled, perfectly adequately, by an Ada abstraction

(typically a procedure
> or function). Furthermore, you get something extra in

making that
> abstraction: encapsulation (factoring out common code),

and a degree of
> self-documentation (the name of the subprogram says what

it does).
>
> -------------------------------------
> Nick Roberts
> -------------------------------------
>
>

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

Re: should I be interested in ada?

[Nick Roberts]

robert_dewar@my-dejanews.com wrote in message
<7aldu1$4q$1@nnrp1.dejanews.com>...
|In article <7akvao$j5t$2@plug.news.pipex.net>,
|  "Nick Roberts" <Nick.Roberts@dial.pipex.com> wrote:
|
|>    Reorder(X,J)
|
|>
|> You've got to declare a utility procedure, certainly, but
|> otherwise this is just as neat as the Fortran, surely?
|
|My goodness one would almost think that Nick was trying to
|make Ada look bad by making dubious arguments.

I am certainly not trying to do this!

|First, the
|Ada code is far uglier and less safe than the Fortran code,

Hearsay. This is a totally subjective opinion (either way I suppose), isn't
it?

|I really cannot imagine anyone thinking otherwise.

To be honest, I would be interested in seeing a greater variety of opinions
(please!). Robert does not seem to have procduced any counter-argument to my
point about the advantages of abstraction.

|But
|more importantly, the Ada code does not catch the semantics
|of the FORALL at all, there is no parallelism at all in the
|Ada code, and indeed it is quite likely that not even a
|clever optimizer can bail this out, because, as always it
|is the exceptions that get you in Ada (if an exception is
|raised, the semantics dictate exactly which iterations of
|the loop have occured and which have not). Nick has
|conveniently ignored this in his thinking, but it turns
|out to be absolutely crucial. All sorts of loops in Fortran
|that can be assumed to be parallel by the optimizer even if
|FORALL is not used CANNOT be assumed to be parallel in Ada
|because of the exception issue.

I think this point is essentially wrong, in that the cases where the Ada
optimiser cannot produce code which is just as good (as the Fortran code
with or without FORALL) will be very rare, in practice.

Perhaps Robert should re-read RM95 11.6 (6). Only the intervention of an
independant subprogram (in the loop) would cause the problems he suggests.
In most code, there will be no such subprogram, but, anyway, in just about
any speed critical code an independant subprogram can almost always be
avoided (by changing the place its body is declared in the source text, or
making it inline).

|This means that FOR ALL is in a sense even more crucial
|in Ada (which doesn't have it) than in Fortran 95 (which
|does).
|
|All this was covered in rather excruciating detail in the
|thread a few years ago about implementing FOR ALL in Ada.


I never saw this thread: I shall have a little search on DN. [The trouble
with DN is that there must be tens of thousands of posts per year, even on a
'signal-dense' NG like CLA. To review it all would be a Herculean task (give
a smelly stables any day :-).]

[BTW I would like to restate that I am very pleased - most gratified
really -  to see answers to my silly posts from the likes of Professor
Dewar, a man who has a rare depth of experience in the field (of computer
science and the development of programming languages). My personal
philosophy is that the only way to learn is to make mistakes. To have your
mistakes pointed out to you by the experts is a privilege. I say what I
really think (you may have noticed ;-), and I do not give praise lightly.]

-------------------------------------
Nick Roberts
-------------------------------------

Re: should I be interested in ada?

[William Clodius]

Nick Roberts wrote:
> 
> robert_dewar@my-dejanews.com wrote in message
> <7aldu1$4q$1@nnrp1.dejanews.com>...
> <snip>
> |First, the
> |Ada code is far uglier and less safe than the Fortran code,
> 
> Hearsay. This is a totally subjective opinion (either way I suppose), isn't
> it?

All other things being equal, the more code it takes to do something the
more error prone it is. Although all other things are rarely equal, the
FORALL code is very easy for humans and compilers to parse and
understand. Once the programmer understands it he finds it usefull and
uses it a lot so that it does not remain an obsure idiom to those
familar with the language. There is therefore no obvious other quality
to the Ada code that counterballance the negative effects of a much
longer length.

> 
> |I really cannot imagine anyone thinking otherwise.
> 
> To be honest, I would be interested in seeing a greater variety of opinions
> (please!). Robert does not seem to have procduced any counter-argument to my
> point about the advantages of abstraction.

I don't think anyone will argue with you about the virtues of
abstraction, but every language has a finite definition, and that finite
definition intrinsically limits how well an abstraction can match the
semantics of a specific context. In particular FORALL and WHERE are
abstractions that convey directly the concept of parallelism and array
element relationships that can only be indirectly inferred from your
equivalent. They are abstractions that in practice appear to be most
useful in the context of (high performance) numerics, so they have not
gained wide currency, but application specific abstractions are a very
usefull aspect of domain specific languages, and Fortran continues to
emphasize numerics and high performance in its definition.
> <snip>

-- 

William B. Clodius		Phone: (505)-665-9370
Los Alamos Nat. Lab., NIS-2     FAX: (505)-667-3815
PO Box 1663, MS-C323    	Group office: (505)-667-5776
Los Alamos, NM 87545            Email: wclodius@lanl.gov

Re: should I be interested in ada?

[robert_dewar]

In article <7aslfp$gpq$1@plug.news.pipex.net>,
  "Nick Roberts" <Nick.Roberts@dial.pipex.com> wrote:

> Perhaps Robert should re-read RM95 11.6 (6). Only the
> intervention of an independant subprogram (in the loop)
> would cause the problems he suggests.

Well that's good for a laugh! Robert helped write 11.6,
and has spent hundreds of hours over the years
understanding what it means. If you think it really means
that Ada can provide as much parallelism as Fortran, it is
probably you who are misreading 11.6. This is a pretty
(in)famous section of the RM. All of us know this number
so well that we insisted that the same section number be
used in RM 95 (we just could not imagine this being called
anything but 11.6). 11.6(6) has been discussed and
dissected over a long period, but there is nothing in it
to suggest that the kind of parellelism you suggest is
possible. For example:

   for all J in 1 .. N loop
     S := S + D(J);
   end loop;

The FOR ALL here implies that the additions can be done
in any order. If we write the above loop without the ALL,
there is ABSOLUTELY no permission anywhere in the RM
(including in 11.6(6) that would allow the additions to
be done in other than the canonical order). Note that
the model interval of the result can of course be changed
by changing the order of additions!

There are many other similar examples



> In most code, there will be no such subprogram, but,
anyway, in just about
> any speed critical code an independant subprogram can
almost always be
> avoided (by changing the place its body is declared in
the source text, or
> making it inline).
>
> |This means that FOR ALL is in a sense even more crucial
> |in Ada (which doesn't have it) than in Fortran 95 (which
> |does).
> |
> |All this was covered in rather excruciating detail in
the
> |thread a few years ago about implementing FOR ALL in
Ada.
>
> I never saw this thread: I shall have a little search on
DN. [The trouble
> with DN is that there must be tens of thousands of posts
per year, even on a
> 'signal-dense' NG like CLA. To review it all would be a
Herculean task (give
> a smelly stables any day :-).]
>
> [BTW I would like to restate that I am very pleased -
most gratified
> really -  to see answers to my silly posts from the likes
of Professor
> Dewar, a man who has a rare depth of experience in the
field (of computer
> science and the development of programming languages). My
personal
> philosophy is that the only way to learn is to make
mistakes. To have your
> mistakes pointed out to you by the experts is a
privilege. I say what I
> really think (you may have noticed ;-), and I do not give
praise lightly.]
>
> -------------------------------------
> Nick Roberts
> -------------------------------------
>
>

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

Re: should I be interested in ada?

[Nick Roberts]

robert_dewar@my-dejanews.com wrote in message
<7atdf0$gu6$1@nnrp1.dejanews.com>...
[...]
|but there is nothing in it
|to suggest that the kind of parellelism you suggest is
|possible. For example:
|
|   for all J in 1 .. N loop
|     S := S + D(J);
|   end loop;
|
|The FOR ALL here implies that the additions can be done
|in any order. If we write the above loop without the ALL,
|there is ABSOLUTELY no permission anywhere in the RM
|(including in 11.6(6) that would allow the additions to
|be done in other than the canonical order). Note that
|the model interval of the result can of course be changed
|by changing the order of additions!
|
|There are many other similar examples
[...]


Is this a wind up? How about section 1.1.3, which states that "the execution
of an Ada program is defined in terms of its interactions with the external
environment"? Only conformance with Annex G (in 'strict mode') causes 'model
intervals' to be a restriction on optimisations. The Fortran 90 standard has
no such strictures (even as an option), and it doesn't offer a fixed-point
type. Be serious, please.

-------------------------------------
Nick Roberts
-------------------------------------

Re: should I be interested in ada?

[William Clodius]

Nick Roberts wrote:
> <snip>
> This is a simple example, granted. But, it can be done without undue
> difficulty in Ada by declaring an appropriate procedure:
> 
>    procedure Reorder (Object: in out Vector; Index: in Selection) is
>       Temp: constant Vector := Object;
>    begin
>       for i in Index'Range loop
>          Object(Index(i)) := Temp(i);
>       end loop;
>    end;
> <snip>

Even neglecting parallelization issues, the above code does not catch
the semantics of the FORALL loop, in particular the FORALL does not
require that either X or J be dimensioned 1:N, only that:

1. the index range include 1:N;
2. X's range include all values of J(1:N); and
3. the values of J(1:N) not have any duplicates.

As a result Temp as declared above is assumed to be larger than the
requirements might actually be, and Index might range past the desired
bounds.

-- 

William B. Clodius		Phone: (505)-665-9370
Los Alamos Nat. Lab., NIS-2     FAX: (505)-667-3815
PO Box 1663, MS-C323    	Group office: (505)-667-5776
Los Alamos, NM 87545            Email: wclodius@lanl.gov

Re: should I be interested in ada?

[Nick Roberts]

William Clodius wrote in message <36D1D862.41C6@lanl.gov>...
[...]
|>    procedure Reorder (Object: in out Vector; Index: in Selection) is
|>       Temp: constant Vector := Object;
|>    begin
|>       for i in Index'Range loop
|>          Object(Index(i)) := Temp(i);
|>       end loop;
|>    end;
|> <snip>
|
|Even neglecting parallelization issues, the above code does not catch
|the semantics of the FORALL loop, in particular the FORALL does not
|require that either X or J be dimensioned 1:N, only that:
|
|1. the index range include 1:N;
|2. X's range include all values of J(1:N); and
|3. the values of J(1:N) not have any duplicates.
|
|As a result Temp as declared above is assumed to be larger than the
|requirements might actually be, and Index might range past the desired
|bounds.


Its true that the Ada code doesn't capture the same semantics - essentially
that no component of Object will be assigned more than once (and they can be
assigned in any order) - but I'm not sure that this will make any difference
in practice (for a non-parallel target).

The Ada procedure is inlined, so the optimizer may have the opportunity to
eliminate null operations (e.g. assignment to self). I think Temp being too
long will often not be a problem (for a clever dataflow analysing
optimiser). Anyway, the problem can always be got around 'by force', by
passing one or two more parameters into the procedure.

As for the 'parallelization issues', possibly one or two pragmas might help
for SIMD machines (as suggested by another poster recently, I think).

   pragma Assume(Parallel_Update,Object);
   pragma Assume(Spanning_Bijection,Index);

This is, admittedly, a bit hypothetical, since (to my knowledge) there is no
Ada compiler targetting a SIMD architecture, and no immediate prospect of
there being one.

Parallel processor targets can be catered for, in Ada, by encapsulating a
multiple-task solution inside a procedure. I have constructed such a thing
myself (for matrix inversion), as a 'technology demonstrator'. Not neat, but
effective.

|William B. Clodius Phone: (505)-665-9370
|Los Alamos Nat. Lab., NIS-2     FAX: (505)-667-3815
|PO Box 1663, MS-C323    Group office: (505)-667-5776
|Los Alamos, NM 87545            Email: wclodius@lanl.gov

-------------------------------------
Nick Roberts
-------------------------------------

Re: should I be interested in ada?

[William Clodius]

Ni<snip>
> Its true that the Ada code doesn't capture the same semantics - essentially
> that no component of Object will be assigned more than once (and they can be
> assigned in any order) - but I'm not sure that this will make any difference
> in practice (for a non-parallel target).

The above "essentially" demphasizes my main point, that it also doesn't
capture the semantics that the assignment may involve only part of the
objects X and J. 

>
> The Ada procedure is inlined, so the optimizer may have the opportunity to
> eliminate null operations (e.g. assignment to self). I think Temp being too
> long will often not be a problem (for a clever dataflow analysing
> optimiser). Anyway, the problem can always be got around 'by force', by
> passing one or two more parameters into the procedure.
> <snip>

Note the fact that the intended assignment may involve only part of J,
means that your code might not only be inefficient, but also incorrect.

In thinking about this further, one additional problem to me is the
decision to make this an explicit procedure. I would normally do this
only under circumstances that need not apply to this case, i.e., if I
were going to use it at multiple points in the code or if it were doing
a complicated task that is easilly summarized. Under those circumstances
I would want a well documented routine. Reorder by itself could mean the
equivalent of any of the following

FORALL (I=1:N) X(J(I)) = X(I)
FORALL (I=1:N) X(I) = X(J(I))
FORALL (I=1:N) X(21-J(I)) = X(J(I))
FORALL (I=1:N) X(J(I)) = X(21-J(I))

The isolation of the code in this way makes it more difficult to verify
that it has the semantics required in the context in which it is
currently used, and even if appropriate there, increases the chance that
it will be reused in inappropriate contexts.

-- 

William B. Clodius		Phone: (505)-665-9370
Los Alamos Nat. Lab., NIS-2     FAX: (505)-667-3815
PO Box 1663, MS-C323    	Group office: (505)-667-5776
Los Alamos, NM 87545            Email: wclodius@lanl.gov

Re: should I be interested in ada?

[Nick Roberts]

William Clodius wrote in message <36D33B65.446B@lanl.gov>...
|Ni<snip>
|> Its true that the Ada code doesn't capture the same semantics -
essentially
|> that no component of Object will be assigned more than once (and they can
be
|> assigned in any order) - but I'm not sure that this will make any
difference
|> in practice (for a non-parallel target).
|
|The above "essentially" demphasizes my main point, that it also doesn't
|capture the semantics that the assignment may involve only part of the
|objects X and J.


I apologise; it's not my intention to use rhetoric to defeat your example.

In the case of the Reorder procedure example I gave, a part of X could be
reordered simply by passing a part of it into the call, e.g.:

   Reorder(X(a..b),J);

The domain of J could be restricted by the same method, and its range by
introducing two new parameters to the procedure, e.g.:

   Reorder(X(a..b),J(a..b),a,b);

Again, not neat, but workable.

|In thinking about this further, one additional problem to me is the
|decision to make this an explicit procedure. I would normally do this
|only under circumstances that need not apply to this case, i.e., if I
|were going to use it at multiple points in the code or if it were doing
|a complicated task that is easilly summarized. Under those circumstances
|I would want a well documented routine. Reorder by itself could mean the
|equivalent of any of the following


I used a procedural abstraction, because it seemed appropriate in this case.
In cases where an abstraction would not be appropriate, in-line code could
be used instead.

|The isolation of the code in this way makes it more difficult to verify
|that it has the semantics required in the context in which it is
|currently used, and even if appropriate there, increases the chance that
|it will be reused in inappropriate contexts.


So, in these cases, the inline Ada code ends up being substantially longer
than the Fortran.  However, if you were to take a typical Fortran program,
and translate it into Ada, would you end up with a program that was
substantially bigger (more than two times, say)?  Would have any really
thorny problems in doing the translation?  I would say "very unlikely" to
both questions.

I suppose it now falls to me to illustrate this with an example! :-)

|William B. Clodius Phone: (505)-665-9370
|Los Alamos Nat. Lab., NIS-2     FAX: (505)-667-3815
|PO Box 1663, MS-C323    Group office: (505)-667-5776
|Los Alamos, NM 87545            Email: wclodius@lanl.gov

-------------------------------------
Nick Roberts
-------------------------------------

Re: should I be interested in ada?

[robert_dewar]

In article <7b2j2u$drp$1@plug.news.pipex.net>,
  "Nick Roberts" <Nick.Roberts@dial.pipex.com> wrote:
> In the case of the Reorder procedure example I gave, a
> part of X could be reordered simply by passing a part of
> it into the call, e.g.:
>
>    Reorder(X(a..b),J);

This misses a central point. Slices in Ada can only be
applied to one dimensional arrays. This (very
understandable) restriction is a significant one in
the context of numerical codes dealing with multi-
dimensional arrays.

The reason for the restriction is of course that otherwise
strides are not known at compile time in many cases where
they are known now, and that is a worrisome inefficiency.
(this has been well studied in the context of Algol-68,
which as far as I know was the first main stream language
to allow general slicing).

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

Re: should I be interested in ada?

[Robert I. Eachus]

In article <36CD8DBA.237C@lanl.gov> William Clodius <wclodius@lanl.gov> writes:

  > Perhaps the best simple example is the FORALL statement to do a
  > reordering of elements

  > FORALL (I=1:N) X(J(I)) = X(I)

  > which in Ada would require the explicit creation of a temporary to hold
  > the value of X, assignment to the temporary, and then the assignment of
  > the temporary to X. Note it is required that the values of J(1:N) not
  > duplicate one another and lie within the dimensioned ranges of X.

  Ignoring for the moment the other discussion on this issue, there are
two similar constructs in Ada which have somewhat different restrictions.

    X := (X(4),X(3),X(2),X(1));

  Would reverse the (four) elements of the array X.  The problem is that,
for this notation, the subscripts are required to be static.  You can
do:

   X := (N => 1, others => 0);

   where N is non-static, or better:

   X := X(N) & X(P) & X(Q) & X(R);

   Again the length is set by the syntax, but N,P,Q, and R need not be
static.  There is a very interesting interaction here between
optimization and staticness.  Before the assignment happens, the
subscripts must be bounds checked, but if their subtype conforms, the
check does not need to be done, allowing the assignments to proceed in
parallel.  Of course, you need to copy the values before writing,
otherwise you get junk.

   Lets go a bit further:

   X: String := Some_expression;
   N: Integer range X'Range := ...;

   X := X(N..X'Last) & X(X'First..N-1);

   Now the computer can go to town.

   So Ada does have some idioms that can duplicate part of the
functionality of FORALL, but it really would have been nice to add it
to Ada 95.  Maybe next time.  (I never really understood why it didn't
make it in.  There is a trivial syntax change associated with it, but
compilers for low end machines could just treat it like a normal for
loop.)
--

					Robert I. Eachus

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

Re: should I be interested in ada?

[Nick Roberts]

Robert I. Eachus wrote in message ...
[...]
|   So Ada does have some idioms that can duplicate part of the
|functionality of FORALL, but it really would have been nice to add it
|to Ada 95.  Maybe next time.  (I never really understood why it didn't
|make it in.  There is a trivial syntax change associated with it, but
|compilers for low end machines could just treat it like a normal for
|loop.)

I suggest pragmas in another post, which I think could be workable. They
can't be used to change the semantics of any construct, but they can be used
to give the compiler more information about its semantics.


It also occurs to me that future additions to the Ada standard library might
profitably include quite a variety of elemental vector and matrix operations
(rotate, shift, sort, vector/matrix arithmetic, etc.).

I think it was mentioned recently in CLA that there should be a Fortran
package to provide Fortran facilities (e.g. ROTATE) for Ada: perhaps these
would be better provided 'straight' instead.

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

-------------------------------------
Nick Roberts
-------------------------------------

Re: should I be interested in ada?

[Robert A Duff]

"Nick Roberts" <Nick.Roberts@dial.pipex.com> writes:

> I suggest pragmas in another post, which I think could be workable. They
> can't be used to change the semantics of any construct, ...

Where do you get *that* idea?

- Bob
-- 
Change robert to bob to get my real email address.  Sorry.

Semantic info pragmas (was: should I be interested in ada?)

[Nick Roberts]

Robert A Duff wrote in message ...
|> I suggest pragmas in another post, which I think could be workable. They
|> can't be used to change the semantics of any construct, ...
|
|Where do you get *that* idea?


RM95 2.8(16) states "Normally, implementation-defined pragmas should have no
semantic effect for error-free programs; ...," so I should have said
'shouldn't' rather than 'can't'.  I think this is an area where there would
be no good excuse for introducing implementation-defined pragmas which did
change the semantics.

Note that a careful distinction needs to be made here between a pragma which
_changes_ the semantics of a construct, and a pragma which informs the
compiler of a semantic characteristic which (in the absence of errors) the
construct _already has_ (but which the compiler might not be able to deduce
on its own).

Note also (for the benefit of the pedants among us :-) that I am not
including execution timing in the meaning of the word 'semantics' in this
context (and I assume the same is true of the RM95).

-------------------------------------
Nick Roberts
-------------------------------------

Re: Semantic info pragmas (was: should I be interested in ada?)

[Samuel Tardieu]

>>>>> "Nick" == Nick Roberts <Nick.Roberts@dial.pipex.com> writes:

Nick> RM95 2.8(16) states "Normally, implementation-defined pragmas
Nick> should have no semantic effect for error-free programs; ...," so
Nick> I should have said 'shouldn't' rather than 'can't'.  I think
Nick> this is an area where there would be no good excuse for
Nick> introducing implementation-defined pragmas which did change the
Nick> semantics.

"Normally" means "except where specified", right? Because pragma
Asynchronous certainly does change the semantics of a procedure call
in regard with exceptions.

  Sam
-- 
Samuel Tardieu -- sam@ada.eu.org

Re: Semantic info pragmas (was: should I be interested in ada?)

[Robert A Duff]

Samuel Tardieu <sam@ada.eu.org> writes:

> >>>>> "Nick" == Nick Roberts <Nick.Roberts@dial.pipex.com> writes:
> 
> Nick> RM95 2.8(16) states "Normally, implementation-defined pragmas
> Nick> should have no semantic effect for error-free programs; ...," so
> Nick> I should have said 'shouldn't' rather than 'can't'.  I think
> Nick> this is an area where there would be no good excuse for
> Nick> introducing implementation-defined pragmas which did change the
> Nick> semantics.

There's an important difference between "shouldn't" and "can't".

A bit of history: During the language design, Tucker wanted to put in a
"shall" rule along the lines of the above.  I wanted to leave it out,
and rely on implementer's "good taste" to prevent really awful pragmas.
We argued strongly, and eventually compromised on putting in the rule,
but weakening it by labelling it "Implementation Advice", and using
"should".  That compromise was unusual -- for most design decisions, we
either agreed, or kept arguing until we did agree.  ;-)

(I don't think you can capture "good taste" in a rule.  But as a
guideline, I think pragmas shouldn't have a "strong" effect on the
semantics of working programs, whatever that means.  A pragma that
restricts is usually in good taste.)

> "Normally" means "except where specified", right? Because pragma
> Asynchronous certainly does change the semantics of a procedure call
> in regard with exceptions.

I wrote "Normally" deliberately to further weaken the rule.  I meant it
to indicate that there are perfectly reasonable pragmas that would
violate the rule.

Asynchronous is an interesting example:

During the language design, we had a meta-rule: any feature we put in
one of the optional annexes had to be something that a compiler vendor
could have "legally" added to the language as an implementation-defined
feature.  So in the optional annexes, you will find pragmas, attributes,
packages, and some nailing-down of semantics that is looser in the core
language.  You will certainly not find any new syntax.

Anyway, given the meta-rule, we had to construct the rules about pragmas
to allow us to do what we wanted in the optional annexes.

Actually, I think pragma Asynchronous is kind of in bad taste.  It has
such a strong effect on procedure-call semantics that I think it
deserves its own syntax.  But we wanted to put it in the optional annex,
so our hands were tied (by ourselves, to some extent!).

- Bob
-- 
Change robert to bob to get my real email address.  Sorry.

Re: should I be interested in ada?

[William Clodius]

Robert I. Eachus wrote:
> <snip>
>    So Ada does have some idioms that can duplicate part of the
> functionality of FORALL, but it really would have been nice to add it
> to Ada 95.  Maybe next time.  (I never really understood why it didn't
> make it in.  There is a trivial syntax change associated with it, but
> compilers for low end machines could just treat it like a normal for
> loop.)
> -<snip>

Minor note the examples Robert quotes for Ada can all be done in Fortran
90 without FORALL but with a slightly different syntax than required by
ADA. DIfferences are that Fortran allows the triplet notation for index
vectors, first value:maximumu value:increment, its array constructor
uses (/.../) rather than (...), implied DO can be used for array
construction, and it doesn't have an array concatonation operator (I
assume that is the meaning of & in Ada).



-- 

William B. Clodius		Phone: (505)-665-9370
Los Alamos Nat. Lab., NIS-2     FAX: (505)-667-3815
PO Box 1663, MS-C323    	Group office: (505)-667-5776
Los Alamos, NM 87545            Email: wclodius@lanl.gov

Re: should I be interested in ada?

[William Clodius]

William Clodius wrote:
> 
> Perhaps the best simple example is the FORALL statement to do a
> reordering of elements
> 
> FORALL (I=1:N) X(J(I)) = X(I)
> 
> <snip>

In thinking about this further, this is not the best example of a FORALL
as the equivalent code can be written slightly more simply without the
FORALL

	X(J(1:N)) = X(1:N)

If X and J are both dimensioned 1:N, then this can be further simplified
to

	X(J) = X

More typical use of a simple FORALL statement would be to assign to
diagonal elements

	FORALL (I=1:N) A(I,I) = X(I)

or the construction of complicated arrays

	FORALL (I=1:N, J=1:M) A(I,J) = I + J

The FORALL construct can be used as a substitute for a WHERE, but WHERE
is usually simpler

	WHERE(A(1:N) == 0.) A(1:N) = B(1:N)


-- 

William B. Clodius		Phone: (505)-665-9370
Los Alamos Nat. Lab., NIS-2     FAX: (505)-667-3815
PO Box 1663, MS-C323    	Group office: (505)-667-5776
Los Alamos, NM 87545            Email: wclodius@lanl.gov

Re: should I be interested in ada?

[Nick Roberts]

William Clodius wrote in message <36D43C64.15FB@lanl.gov>...
[...]

| X(J) = X


I'd say this shows the high-level power of Fortran 90 at its best.  I mean,
this is neat!  This is almost APL (and I mean that as a compliment - APL can
be a really, really neat language).

| FORALL (I=1:N, J=1:M) A(I,J) = I + J


The Ada equivalent would be:

   for i in 1..N loop
      for j in 1..M loop
         A(i,j) := i+j;
      end loop;
   end loop;

You might say "that's five times bigger!"  But I would strongly contend that
it would be highly naive to think that because one piece of code is five
lines and another is one line, it must therefore be five times more complex
(in terms of diffculty to read, difficulty to debug, etc.).

| WHERE(A(1:N) == 0.) A(1:N) = B(1:N)

The Ada would be:

   for i in 1..N loop
      if A(i) = 0.0 then A(i) := B(i); end if;
   end loop;

Less neat, certainly. But I think similar comments apply as to the previous
example.

|William B. Clodius Phone: (505)-665-9370
|Los Alamos Nat. Lab., NIS-2     FAX: (505)-667-3815
|PO Box 1663, MS-C323    Group office: (505)-667-5776
|Los Alamos, NM 87545            Email: wclodius@lanl.gov

-------------------------------------
Nick Roberts
-------------------------------------

Re: should I be interested in ada?

[robert_dewar]

In article <7b2j32$drp$2@plug.news.pipex.net>,
  "Nick Roberts" <Nick.Roberts@dial.pipex.com> wrote:

> But I would strongly contend that
> it would be highly naive to think that because one piece
> of code is five lines and another is one line, it must
> therefore be five times more complex (in terms of
> diffculty to read, difficulty to debug, etc.).

When you "strongly contend" something that is contrary
to general experience and data collected in the industry
(which shows that productivity is very closely connected
to lines of source code, and that higher level abstractions
do indeed reduce complexity from the points of view you
mention, you need something more than received wisdom from
personal communication with the oracle. You could appeal
to 50 years of personal experience, but even that would
be dubious in this case. You need to present some evidence.
This is after all an issue that is VERY well studied, and
for which there is lots of published data. You are
contesting this data. Fine, that's how we make progress in
science, but you need some evidence, or at the very least
some convincing reasoning.

I must say that the trading of examples here is very
effective in showing the power of Fortran 90 in these
areas!

> Less neat, certainly. But I think similar comments apply
> as to the previous example.

So let me get this straight.

You replace one neat line by several "less neat" lines, and
yet you still "strongly contend" [without evidence or even
reasoning, convincing or otherwise] that this makes no
difference in productivity, maintainability, or
readability.

If we follow this contention to its extreme, we may as well
all go back to programming in absolute machine language!
I assume that is absurd, but in the absence of any kind of
reasoning to back up the contention here, it is hard to see
how it does not apply in a very general manner.

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

Re: should I be interested in ada?

[Nick Roberts]

I'm sticking to my contention, in this case, with no diminished strength.

My argument would be based on the assertion that the complexity of a piece
of code, given that the programmer is already well familiar with those
aspects of the language which are the same in every program (e.g. the
spelling or symbol used for each language primitive), will depend on those
aspects of the program which do vary from program to program (e.g. the
elements present, and their relationship to each other).

Let us first review the Fortran and Ada snippets:

   FORALL (I=1:N, J=1:M) A(I,J) = I + J

   for i in 1..N loop
      for j in 1..M loop
         A(i,j) := i+j;
      end loop;
   end loop;

Now let us reassign each primitive element of the Fortran structure as
follows:

[01]  the FORALL structure
[02]  the () structure enclosing the iteration schemes
[03]  the , separating the iteration schemes and array indices
[04]  the = separating the iterative variable from the iterative range, and
destination from assignment source
[05]  the : separating the range start from the range end
[06]  the () surrounding an array index
[07]  the + operation
[08]  the variable I
[09]  the variable J
[10]  the array A
[11]  the literal 1
[12]  the integer N
[13]  the integer M

And then the same for the Ada:

[01]  the loop ... end loop; structure
[02]  the for ... iteration scheme structure
[03]  the 'in' dividing the iterative variable from the range
[04]  the '..' dividing the range start from the range end
[05]  the () surrounding an array index
[06]  the , separating array indices
[07]  the := assignment operation
[08]  the + operation
[09]  the variable i
[10]  the variable j
[11]  the array A
[12]  the integer N
[13]  the integer M
[14]  the literal 1

Now let us show these two structures, in terms of their component elements
and their relationships, in a manner that bears direct comparison:

[01]( [02]( [03]( [04]( [08], [05]( [11], [12] ) ), [04]( [09], [05]( [11],
[13] ) ) ), [04]( [06]( [10], [03]( [08], [09] ) ), [07]( [08], [09] ) ) )

[01]( [02]( [03]( [09], [04]( [14], [12] ) ) ), [01]( [02]( [03]( [10],
[04]( [14], [13] ) ) ), [07]( [05]( [11], [06]( [09], [10] ) ), [08]( [09],
[10] ) ) ) )

And lo and behold!  They're almost identical in complexity.  This is
elementary language science.

I believe SLOCs are used as a measure between different programs written in
the same language mainly because it is the simplest method, rather than
because it is considered a particularly good method of measurement, and, in
any case, are (almost) never used to compare the same program written in
different languages.  If SLOCs were such a good measure, why would so many
scientists be seeking to develop other methods of code measurement (e.g. the
CGD of the GRASP project)?

Finally, if an Assembly equivalent of the above algorithm were to be
semiotically analysed in the same way as I have done above, it would produce
a result that was less deeply nested, but contained a much longer stream of
elements (five times or more).  The advantages of using a HLL over Assembly
are many, reduced complexity (or at least increased conciseness) being just
one.

-------------------------------------
Nick Roberts
-------------------------------------

Re: should I be interested in ada?

[Jerry Petrey]

Nick Roberts wrote:
> 
> robert_dewar@my-dejanews.com wrote in message
> <7afttr$7v3$1@nnrp1.dejanews.com>...
> |In article <7afc1o$3mi$2@plug.news.pipex.net>,
> |  "Nick Roberts" <Nick.Roberts@dial.pipex.com> wrote:
> |> Other than this, there's nothing Fortran can do that Ada
> |> cannot, and quite a few things that Ada can do better. It
> |> may be, in practice, that sometimes Fortran compilers
> |> can/will produce faster object code, but I think this is,
> |> in every case (or almost), only a matter of practice,
> |> rather than a theoretical limit.
> |
> |Yes of course all languages are Turing complete, so of
> |course you can do anything in any language, but Fortran-90
> |has many features not present in Ada. To give just one
> |example, it has a much more sophisticated mechanism for
> |dealing with array aggregates and array aggregate
> |operations.
> 
> Maybe I could have phrased it a little more clearly. I meant there's nothing
> Fortran can do that Ada cannot also do reasonably easily. Certainly, Fortran
> has some convenience notations that are not so convenient in Ada. To take
> Fortran's array facilities as an example, in Fortran one can put:
> 
>    real, dimension (1:10) :: x
>    ...
>    x = 1.0
> 
> setting all the elements of x to 1.0 (a 'broadcast scalar'), whereas in Ada
> to do the same thing, you must code something like:
> 
>    X: array (1..10) of Float;
>    ...
>    for i in X'Range loop X(i) := 1.0; end loop;
> 


I think using an aggregate would be much better than a loop:

X := (1 .. 10 => 1.0);



Jerry
-- 
=====================================================================
=  Jerry Petrey - Consultant Software Engineer  - Member Team Ada   =
=                 Lockheed Martin                 Member Team Forth =
=====================================================================

Re: should I be interested in ada?

[Nick Roberts]

Jerry Petrey wrote in message <36CC11A1.C7A71642@hercii.mar.lmco.com>...
[...]
|> Fortran's array facilities as an example, in Fortran one can put:
|>
|>    real, dimension (1:10) :: x
|>    ...
|>    x = 1.0
|>
|> setting all the elements of x to 1.0 (a 'broadcast scalar'), whereas in
Ada
|> to do the same thing, you must code something like:
|>
|>    X: array (1..10) of Float;
|>    ...
|>    for i in X'Range loop X(i) := 1.0; end loop;
|
|
|I think using an aggregate would be much better than a loop:
|
|X := (1 .. 10 => 1.0);


Precisely right, of course.

Also, Fortran's 'index vector' feature, e.g.:

   x = 0.0
   x( (/ 2, 7, 1, 4, 9 /) ) = b+0.5

can sometimes be directly emulated fairly easily by an Ada aggregate:

   X := (2|7|1|4|9 => B+0.5, others => 0.0);

and any other index vector operations, e.g.:

   x(  (/ 2, 7, 1, 4, 9 /) ) = x( (/ 8, 10, 3, 5, 6 /) )

can be easily done in Ada, using one or two utility procedures or functions,
e.g.:

   type Selection is array (Positive range <>) of Integer;
   ...
   function Extract (V: in Vector; S: in Selection) return Vector is
      Result: Vector(S'Range);
   begin
      for i in S'Range loop Result(i) := V(S(i)); end loop;
      return Result;
   end;

   procedure Insert (Object: in out Vector; Which: in Selection; Value: in
Vector) is
   begin
      for i in Which'Range loop
         Object(Which(i)) := Value(i);
      end loop;
   end;

and then a call such as:

   Insert(X, (2, 7, 1, 4, 9), Extract(X, (8, 10, 3, 5, 6)));

Having built your 'helper' functions and procedures, there really is nothing
in Fortran that cannot be done almost as easily (and as, or almost as,
efficiently) in Ada. My examples have been in terms of array facilities, but
the principle applies to everything else in Fortran.

So, hopefully, my original point stands.

-------------------------------------
Nick Roberts

'The time has come,' the Walrus said,
  'To talk of many things:
Of shoes--of ships--and sealing wax--
  Of cabbages--and kings--
And why the sea is boiling hot--
  And whether pigs have wings.'
                        Lewis Carroll
          "Through the Looking Glass"
-------------------------------------

Re: should I be interested in ada?

[Dan Nagle]

Hello,

Nick Roberts wrote:
> 
<snip requoted material and examples>

> Having built your 'helper' functions and procedures, there really is nothing
> in Fortran that cannot be done almost as easily (and as, or almost as,
> efficiently) in Ada. My examples have been in terms of array facilities, but
> the principle applies to everything else in Fortran.
> 
> So, hopefully, my original point stands.

The only point I would take issue with is the efficiency issue.
Fortran has evolved a stack of rules, including but not limited
to anti-aliasing rules, which make for a great deal of freedom
for an optimizer to work.  (This is the point which usually trips
up the "at last, C/C++  is faster than Fortran" argument.)

I don't know enough about the optimization rules of Ada to know
where Ada stands on this issue, nor do I know how much Ada can
gain from its pragmas.  But raw floating point speed is Fortran's
long suit.

Also, Fortran's intrinsic library has (usually hand) optimized
matrix multiply, dot product, locate maximum element, locate
minimum element, etc.

I know Fortran fairly well, I'm learning Ada and like it so far.
Right now, if I had to fly, I'd like the airplane to be designed
in Fortran, with the fly-by-wire done in Ada.  Just trying to use
the right tool for the right job.

Please feel free to enlighten me about Ada's optimization capabilities.

<snip sig>

-- 

Cheers!
Dan Nagle		dnagle@erols.com

Re: should I be interested in ada?

[nabbasi]

In article <36CC6AC0.25DBE56D@erols.com>, Dan says...
>
>Hello,
>
>Nick Roberts wrote:
>> 
 
>> 
>> So, hopefully, my original point stands.
>

>The only point I would take issue with is the efficiency issue.

valid point, but is 'few' more instructions really that important
these days, when 1000 MHZ PC's and workstations are around the corner?

offcourse this is all hand waving on my part, without concrete
numbers and specific tests one would not know.

>
>Also, Fortran's intrinsic library has (usually hand) optimized
>matrix multiply, dot product, locate maximum element, locate
>minimum element, etc.
>

is there a reason why the same could not be done in Ada also?
I assume Fortran has a bigger library of such intrinsic functions,
(last time I programmed in F77 was 15 years ago), but I dont see 
why Ada could not have the same functions implemented.

There is this package for math functions:

ASSET_A_402 Generic Elementary Math Functions:

"These generic Ada packages provide a set of mathematical 
functions that conform to the SIGAda Numerics Working Group's
proposed standard, which is a proposed secondary ISO standard. 

The package as specified consists of 29 functions, which can 
be classified into three families: exponential, trigonometric, and
hyperbolic. 

The exponential family consists of 5 functions: Sqrt(x), Exp(x),
 X**Y, Log(X) and Log(x,Base). 

The trigonometric family consists of 16 functions: the four 
usual trig functions Sin(x), Cos(x), Tan(x), and Cot(x) and the four
inverses Arcsin(x), Arccos(x), Arctan(y,x), and Arccot(x,y) 
constitute 8 of the 16. These 8 functions are approximations to the
corresponding mathematical functions, with 2pi being the period. 
The proposed ISO standard also requires 8 other functions that allow
the user to specify a period (e.g., 360.0). The calling sequences for 
the other 8 are Sin(x,cycle), Cos(x, cycle), ..., and Arccot(y,x,cycle). 

Finally, the hyperbolic family consists of 8 functions: the commonly used
Sinh(x), Cosh(x), Tanh(x), and Coth(x) and the
corresponding inverses Arcsinh(x), Arccosh(x), Arctanh(x), and Arccoth(x). "

to download, see:

 http://direct.asset.com/wsrd/product.asp?pf_id=ASSET%5FA%5F402

Nasser

Re: should I be interested in ada?

[Nick Roberts]

Dan Nagle wrote in message <36CC6AC0.25DBE56D@erols.com>...
[...]
|I don't know enough about the optimization rules of Ada to know
|where Ada stands on this issue, nor do I know how much Ada can
|gain from its pragmas.  But raw floating point speed is Fortran's
|long suit.
|
|Also, Fortran's intrinsic library has (usually hand) optimized
|matrix multiply, dot product, locate maximum element, locate
|minimum element, etc.

'Raw floating point speed' is largely to do with the target architecture.
Those speed-critical operations which are not hard-wired or micro-coded are
carefully implemented in assembly. I don't believe there are any differences
in the opportunities for optimisation between Ada and Fortran (e.g. Ada
supports global variables, it just doesn't force them on you).

Thus, the high-level language is, theoretically, completely immaterial. Of
course, in practice, you may well find Fortran compilers which have better
written libraries and/or better optimisation. And, of course, for
multi-processor targets, there are the (many!) parallelising Fortran
compilers.


|I know Fortran fairly well, I'm learning Ada and like it so far.
|Right now, if I had to fly, I'd like the airplane to be designed
|in Fortran, with the fly-by-wire done in Ada.  Just trying to use
|the right tool for the right job.


Fortran is very much a general-purpose language now. But my curiosity is
piqued: for which part of flying an aeroplane would you consider Fortran to
be the 'right tool for the job'?

|Please feel free to enlighten me about Ada's optimization capabilities.


This is an issue which happens to be close to my heart. I would like someone
to point out to me an optimisation that can be done in Fortran (or any other
general purpose imperative language) which cannot be done in Ada. There may
be such optimisations - I have an open mind - but I have never come across
any yet.

Again, I note that there's always a difference between theory and reality.
What _can_ be done is not always what _is_ done.

-------------------------------------
Nick Roberts
-------------------------------------

Re: should I be interested in ada?

[robert_dewar]

In article <7aikfp$nhq$3@plug.news.pipex.net>,
  "Nick Roberts" <Nick.Roberts@dial.pipex.com> wrote:
> Thus, the high-level language is, theoretically,
> completely immaterial [to quality of fpt code]

Not quite. The aliasing rules for parameters in Fortran
are quite different from those in Ada, and clearly are
preferable from a code generation point of view. How
significant this is in *practice* is open to question,
but in *theory* Fortran can sometimes produce better code.

The operable rule in Fortran is that if there are two paths
to the same variable, then assigning via either path is
erroneous at the point of assignment. The Ada rule is
much more restrictive, depending only on the
value-vs-reference non-determinism.

It is pretty easy to construct examples where Fortran can
assume no aliasing, but Ada still has to worry about
aliasing of parameters.

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

Re: should I be interested in ada?

[Nick Roberts]

robert_dewar@my-dejanews.com wrote in message
<7ajkhb$dol$1@nnrp1.dejanews.com>...
|In article <7aikfp$nhq$3@plug.news.pipex.net>,
|  "Nick Roberts" <Nick.Roberts@dial.pipex.com> wrote:
|> Thus, the high-level language is, theoretically,
|> completely immaterial [to quality of fpt code]
|
|Not quite. The aliasing rules for parameters in Fortran
|are quite different from those in Ada, and clearly are
|preferable from a code generation point of view. How
|significant this is in *practice* is open to question,
|but in *theory* Fortran can sometimes produce better code.


Correct for most existing Ada and Fortran compilers. However, I do not
believe that this would be true for an Ada compiler which generates code
'late' (i.e. effectively at the linking stage).

Under alias analysis, an Ada subprogram which is never called with aliased
parameters (i.e. two or more by-reference parameters which have the same
object as actuals) can be compiled to assume the corresponding formals will
never be aliased. This assumption is useful (only) where one or both
parameters are modified, because it allows rescheduling (and sometimes other
optimisations) of the writes. 'Late code' compilers can always do this
analysis globally, and thus can always perform this potential optimisation.

I believe there is a trend, these days, for aggressively optimising
compilers to be of the 'late code' persuasion (mine will be). Of course,
admittedly, even such compilers cannot get round the problem for the
generation of a 'shared object' library (aka DLL).

On the other hand, ironically, Fortran (77 and 90) often cannot perform this
optimisation (reliably), since the language has always suffered from the
fact that not all compilers have enforced the 'no aliasing' rule, and
therefore many programs (unfortunately) have been written which take
advantage of this fact.

-------------------------------------
Nick Roberts
-------------------------------------

Re: should I be interested in ada?

[William Clodius]

Nick Roberts wrote:
> <snip>
> Correct for most existing Ada and Fortran compilers. However, I do not
> believe that this would be true for an Ada compiler which generates code
> 'late' (i.e. effectively at the linking stage).
> <snip>

Wrong. For better or worse, the Fortran standard allows the assumption
of no aliasing even under circumstances where proof that no aliasing
occurs involves solving the halting problem.

-- 

William B. Clodius		Phone: (505)-665-9370
Los Alamos Nat. Lab., NIS-2     FAX: (505)-667-3815
PO Box 1663, MS-C323    	Group office: (505)-667-5776
Los Alamos, NM 87545            Email: wclodius@lanl.gov

Re: should I be interested in ada?

[Nick Roberts]

William Clodius wrote in message <36CDE19E.2F1C@lanl.gov>...
|Nick Roberts wrote:
|> <snip>
|> Correct for most existing Ada and Fortran compilers. However, I do not
|> believe that this would be true for an Ada compiler which generates code
|> 'late' (i.e. effectively at the linking stage).
|> <snip>
|
|Wrong. For better or worse, the Fortran standard allows the assumption
|of no aliasing even under circumstances where proof that no aliasing
|occurs involves solving the halting problem.


I concede this; it is true. However, I would assert that situations where
the occurrence of aliasing cannot be disproved are rare, in practice. It is
moderately unusual for a subprogram to be declared which has two parameters
of the same type (or the same dimensionality and base type), and which
updates one or both.

It is quite possible for the compiler to generate two object code versions
for such a subprogram (one for parameters definitely non-aliased, one for
otherwise), and call the appropriate one at different call sites. It is also
possible for the compiler to put a dynamic test in front of the second,
causing it to jump to the first if the aliasable parameters turn out not to
be the same object (this may or may not be worthwhile).

I would be interested if anyone could cite (or show) an example of a real
world Fortran or Ada program having such a subprogram which is called using
parameters that could be aliased, and where an optimiser is unlikely to be
able to determine they are not. (I suspect that there are such programs, but
that they are very rare.)

Nick

Re: should I be interested in ada?

[robert_dewar]

In article <7ald0t$sb$1@plug.news.pipex.net>,
  "Nick Roberts" <Nick.Roberts@dial.pipex.com> wrote:

> I concede this; it is true.

Well that's a remarkable statement, yes I agree something
being true should be reason to "concede" :-) :-)

> However, I would assert that situations where the
> occurrence of aliasing cannot be disproved are rare, in
> practice. It is moderately unusual for a subprogram to be
> declared which has two parameters of the same type (or
> the same dimensionality and base type), and which
> updates one or both.

Well as I said before, more and more, I suspect you have
not written many large Fortran codes. Certainly in the
Fortran systems I have worked on, this is not "moderately
unusual" it is absolutely typical. Furthermore, this is
not a consequence of the language, but rather it is typical
of numerical codes.

A trivial case would be a transposition of a square matrix
with an input array and an output array. A Fortran compiler
can just assume that the two parameters are not aliased,
but an Ada compiler may not make this assumption (even in
Ada 83, where the rules were vaguer and may have allowed
more liberal assumptions, this one is tricky).

Nick, I assume you are aware of the fairly radical change
between Ada 83 and Ada 95 here. In Ada 83, programs that
whose behavior depended on whether parameters are passed
by reference or value are considered erroneous, but in Ada
95 such programs are merely non-deterministic. This can
actually make the situation worse in Ada 95 (the reason
for the change was that the Ada 83 statement was impossible
to formalize). The history here is odd, the original Ada 83
design was an attempt to copy the freedom of Fortran, but
it did not get it quite right, and in particular, the very
clean Fortran rule on when aliasing is invalid was not
copied. The Fortran rule is that assignment via one path
is erroneous if there is more than one path to a variable.

There is no doubt at all that the aliasing information that
can be gathered in an Ada program is less precise than that
in a corresponding Fortran program in this particular case,
and that this situation arises pretty frequently in
practice (Nick, there was a long discussion of this point
in the design process, but I do not know if clear
documentation of this discussion survives).

What is not clear is how much effect this has in practice.
It is reminiscent of the argument that Ada can get more
precise aliasing information than C, and that therefore
Ada compilers should be able to generate better code than
C compilers, other things being equal.

The trouble is that other things are almost never equal,
and individual optimizations are almost always
disappointing in practice.

I would therefore tend to agree that the bottom line effect
here is probably infrequent, but it may occur in tricky
situations. For example, it is easy for a general
formulation of matrix multiplication to run into trouble:

  type X is array (integer range <>,
                   integer range <>) of float;

  procedure Matrix_Mult (A, B : in X; C : out X);

Now remember the Ada rules here, you cannot assume that
A and B are not aliased with C.

If this aliasing *does* occur, it means that the effect
of the code in the body of Matrix_Mult must reflect the
proper semantics with respect to the ordering of statements
if the parameters are passed by reference.

This can *considerably* restrict the ability of the
compiler to reorder statements. For example, if one of
the multiplications in the processing causes a
Constraint_Error, then we must be able to see that exactly
the "right" set of assignments has occured up to that
point, and we can see that effect on the calling
parameters.

This means that at least theoretically, the Fortran
compiler may have an advantage. As I say, whether this
advantage is important in practice, who knows. But note
that this is VERY different from the point Nick makes.
Nick is claiming that this situation does not arise in
practice, when in fact it does arise very often in
practice. The question is not whether it arises, but
how significant it is when it does arise.


> It is quite possible for the compiler to generate two
> object code versions for such a subprogram (one for
> parameters definitely non-aliased, one for
> otherwise), and call the appropriate one at different
> call sites.

Maybe possible ... practical, no!


> I would be interested if anyone could cite (or show) an
> example of a real world Fortran or Ada program having
> such a subprogram which is called using parameters that
> could be aliased, and where an optimiser is unlikely to
> be able to determine they are not. (I suspect that there
> are such programs, but that they are very rare.)

They are in fact common, I gave two obvious examples here,
but if you want more, look at any large linear algebra
package.

One piece of history here is that when this issue was
discussed (rather extensively) by the DR's, I cannot
remember anyone making Nick's claim that the situation
was uncommon. On the contrary we all agreed it was common,
the issue was

(a) can we figure out clean rules in Ada that would allow
appropriate aliasing assumptions to be made (bottom line
answer, we couldn't, the Fortran approach seemed to
radical, since it invalidated previously valid programs).

(b) is the difference important enough to worry about.
Bootom line answer: probably not, based on the kind of
reasoning given above.


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

Re: should I be interested in ada?

[William Clodius]

To summarize - language design can make specific optimizations easier,
but the importance of those optimizations is code dependent and the
degree to which those optimizations are exploited is compiler dependent.
It is not unknown given two different compilers to have one of them do
twice as well as the other on one code and then do half as well on
another code.  I have not seen comparable benchmarks for another
language, but the Fortran benchmarks available through Polyedron's page

http://www.polyhedron.com/

show such variations (particularly for Fortran 90).

-- 

William B. Clodius		Phone: (505)-665-9370
Los Alamos Nat. Lab., NIS-2     FAX: (505)-667-3815
PO Box 1663, MS-C323    	Group office: (505)-667-5776
Los Alamos, NM 87545            Email: wclodius@lanl.gov

Re: should I be interested in ada?

[Nick Roberts]

robert_dewar@my-dejanews.com wrote in message
<7anl92$om3$1@nnrp1.dejanews.com>...
|Well as I said before, more and more, I suspect you have
|not written many large Fortran codes.

Correct, I have written very little Fortran code (for real). What I have
done is to translate an awful lot of Fortran into Ada. The catch is, though,
that this was Fortran 77 (and Ada 83), and quite a few years ago. I do know
Fortran 90, but mostly from an academic point of view (I study languages),
and I appreciate that it is quite a different beast in many ways.

I have studied a lot of languages, both specifically and in general, for
many years now, as well as the various issues relating to computer languages
(especially compilation). I think this has given a fair 'nose' for the
issues, but, as Plato said, "that man is wisest who, like Socrates, realizes
that his wisdom is worthless."

I am also an opera fan (but I don't actually sing ;-).

|Certainly in the
|Fortran systems I have worked on, this is not "moderately
|unusual" it is absolutely typical. Furthermore, this is
|not a consequence of the language, but rather it is typical
|of numerical codes.


I think, possibly, Robert misunderstands, or maybe I didn't put it clearly.
What I mean is that if you were to take a typical program - Fortran or Ada -
and count up (a) the number of subprogram definitions, and then (b) the
number of subprogram definitions which could have aliased parameters, and
then divided (b) by (a), you would almost always get a fairly small ratio
(mostly between 10% and 20% I would guess).

Does anyone have any figures on this sort of thing?

[...]

|> It is quite possible for the compiler to generate two
|> object code versions for such a subprogram (one for
|> parameters definitely non-aliased, one for
|> otherwise), and call the appropriate one at different
|> call sites.
|
|Maybe possible ... practical, no!


Would it really be impractical? I would appreciate anyone expanding on this
point (it is important to me!)?

[...]

I agree with the rest of Robert's post (the substantial part).

[BTW I would like to restate that I am very pleased - most gratified
really -  to see answers to my silly posts from the likes of Professor
Dewar, a man who has a rare depth of experience in the field (of computer
science and the development of programming languages). My personal
philosophy is that the only way to learn is to make mistakes. To have your
mistakes pointed out to you by the experts is a privilege. I say what I
really think (you may have noticed ;-), and I do not give praise lightly.]

-------------------------------------
Nick Roberts
-------------------------------------

Re: should I be interested in ada?

[robert_dewar]

In article <7aknfn$au1$1@plug.news.pipex.net>,
  "Nick Roberts" <Nick.Roberts@dial.pipex.com> wrote:
> Correct for most existing Ada and Fortran compilers.
> However, I do not believe that this would be true for an
> Ada compiler which generates code
> 'late' (i.e. effectively at the linking stage).

No, this is wrong! My statement was not about compilers it
is about languages and the formal definition of when
execution is undefined (and hence what assumptions can
be made).

As surely you must know it is obviously undecidable whether
two parameters are aliased. Yes, analysis of the entire
program (of course impractical in many cases) can determine
additional aliasing information, but that has very little
to do with the observation I made, which was about formal
language definitions.

Fortran has a definite advantage here. If you do not agree,
then there is something you are missing!
> I believe there is a trend, these days, for aggressively
> optimising compilers to be of the 'late code' persuasion
> (mine will be). Of course, admittedly, even such
> compilers cannot get round the problem for the
> generation of a 'shared object' library (aka DLL).

I am not quite sure what you mean by "late code"
persuasion. If you are simply talking about delaying
code generation till link time, this is infeasible in
multi-million line programs, especially given modern
optimization algorithms which tend to be non-linear
in the size of programs. Some modest interprocedural
analysis, perhaps guided by profiling information, is
indeed practical.

> On the other hand, ironically, Fortran (77 and 90) often
> cannot perform this optimisation (reliably), since the
> language has always suffered from the fact that not all
> compilers have enforced the 'no aliasing' rule, and
> therefore many programs (unfortunately) have been written
> which take advantage of this fact.

First of all, it is of course impossible to "enforce" the
no aliasing rule, that is why it such enforcement is
neither expected nor required (it is like uninitialized
variable access in Ada).

It is quite false that compilers do not take advantage of
the aliasing rules of Fortran, they very definitely do, and
I do not know from where you would get a contrary
impression. Even Fortran-2 on the 7090 took advantage of
these rules (which were already enshrined in the Fortran
66 standard).


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

Re: should I be interested in ada?

[William Clodius]

robert_dewar@my-dejanews.com wrote:
> <snip>
> First of all, it is of course impossible to "enforce" the
> no aliasing rule, that is why it such enforcement is
> neither expected nor required (it is like uninitialized
> variable access in Ada).

While it is impossible to correctly identify all instances of aliasing,
in practice:

1. The simplest forms of modifiable aliasing appear to be the most
common, perhaps because most programmers are unsophisticated, and these
forms can be correctly identified.

2. It may be possible to define a usefull heuristics that identifies all
statements with possible instances of modifiable aliasing, but generates
spuriouw warnings. Similar heuristics are being investigated for C in an
attempt to generate acceptable performance with near linear aliasing
analysis.

Because detecting the simple cases does not detect all cases, and the
second case generates spurious warnings, the standard does not require
either capability. I believe some compilers and FTNCHK will generate
warnings for many instances of the first case, and I believe some code
quality verification tools will attempt the second.

> 
> It is quite false that compilers do not take advantage of
> the aliasing rules of Fortran, they very definitely do, and
> I do not know from where you would get a contrary
> impression. Even Fortran-2 on the 7090 took advantage of
> these rules (which were already enshrined in the Fortran
> 66 standard).
> <snip>

Odd!

The 7090 is before my time and I have done very little, if any, IBM
mainframe programming, but I have never heard of Fortran -2. I thought
that untill the late 70's IBM consistently used Roman numerals for its
Fortran compilers, after the first Fortran compiler

Fortran - 1957 often subsesquently referred to as Fortran I
Fortran II - 1958
Fortran III never commercially availlable, used in house and in beta
testing around 1960
Fortran IV - 1962 - the name for most IBM compilers untill the late 70s
Fortran V - 1964, never realy available
Fortran VI - never really available - initial name for what became PL/I

In the first volume of the History of Programming languages, edited by
Wexelblat, Backus goes into detail about the optimizations available for
Forran I and II, which actually match most of the optimizations of
interest here, i.e., the optimizations predated both Fortran 66 and the
7090. I suspect you are actually thinking of Fortran II for the IBM 709.

Most references I have seen state that Fortran IV was primarilly used to
program the 7090, and that for a number of years the Fortran IV compiler
had little or no optimization. (People disliked the long turnaround
times of Fortran II.) I suppose the Fortran II compiler may have also
been available for the 7090, however I would be very surprised if they
put the effort in that would be required to make it compatible with
Fortran 66, which was largely based on the Fortran IV documentation

I had also always assumed that the description of Fortran's argument
passing mechanism was taken with little modification from IBM's manuals
for Fortran IV, which had in turn taken them from Fortran I and Fortran
II for several reasons:

1. The manuals should have described the argument passing mechanism.

2. At the time the Fortran manuals were written no one at IBM (or
perhaps elsewhere in the world) knew how to correctly describe call by
reference, otherwise Backus would have suggested an alternative to call
by name in the development of Algol 60. If call by reference was
implied, the descripotion is the simplest that allows that
implementation.

3. I think (my memory is hazy here) some of the optimizations Backus
describes for Fortran II were not completely compatible with call by
reference.

For what its worth, most Fortran programmers are not aware of Fortran's
argument passing mechanism, but they also don't use the sophisticated
data structures or data access methods where a well defined call by
reference mechanism would be usefull. Aliasing, when it occurs, was not
desired and they would rather have it identified quickly rather than it
have a well defined meaning.

Still there are a number of programs that assume a close approximation
to call by reference semantics. These appear to have been mostly created
on mainframes in the sixties, and personal computers in the late 70's
and early 80's, situations where highly optimizing compilers were rare
or non-existent. In practice, most compilers have low optimization
modes, principally for debugging purposes, which in essence process
statements sequentially, which in turn is sufficient to provide the
desired semantics.

Another Fortran optimization "problem" is the language's assumption that
functions have no significant side effects, which users often want to
use for random number generators or warning flags of various kinds. In
practice the warning flags usually work (although the language does not
define their behavior) when the processor decides to execute the
function, but random number generators implemented as functions are a
notorious source of hard to detect problems with code.

-- 

William B. Clodius		Phone: (505)-665-9370
Los Alamos Nat. Lab., NIS-2     FAX: (505)-667-3815
PO Box 1663, MS-C323    	Group office: (505)-667-5776
Los Alamos, NM 87545            Email: wclodius@lanl.gov

Re: should I be interested in ada?

[Robert I. Eachus]

In article <36D04A5C.7DE1@lanl.gov> William Clodius <wclodius@lanl.gov> writes:

  > The 7090 is before my time and I have done very little, if any, IBM
  > mainframe programming, but I have never heard of Fortran -2. I thought
  > that untill the late 70's IBM consistently used Roman numerals for its
  > Fortran compilers, after the first Fortran compiler

   I programmed a 7090 way back when.  By the time I arrived at MIT,
the 7090s there were, I think, upgraded to 7094's.  (If not the
process was completed within a few months.)

 > In the first volume of the History of Programming languages, edited by
 > Wexelblat, Backus goes into detail about the optimizations available for
 > Forran I and II, which actually match most of the optimizations of
 > interest here, i.e., the optimizations predated both Fortran 66 and the
 > 7090. I suspect you are actually thinking of Fortran II for the IBM 709.

 > Most references I have seen state that Fortran IV was primarilly used to
 > program the 7090, and that for a number of years the Fortran IV compiler
 > had little or no optimization.

   Correct, but anyone doing numerical work on the '90 or '94 used
Fortran II, to get the advantage of the ferocious optimization.  Of
course, you had to throughly debug your code, precisely because of the
problems aliasing could cause during optimization.

 > Another Fortran optimization "problem" is the language's assumption that
 > functions have no significant side effects, which users often want to
 > use for random number generators or warning flags of various kinds. In
 > practice the warning flags usually work (although the language does not
 > define their behavior) when the processor decides to execute the
 > function, but random number generators implemented as functions are a
 > notorious source of hard to detect problems with code.

    I remember, I remember... For the IBM 360 series, there were two
Fortran 66 compilers, FORTRAN G and FORTRAN H.  FORTRAN H had three
optimization levels, 0, 1 and 2.  OPT=0 was stated to be equivalent to
FORTRAN G--it wasn't--and OPT=2 was really fierce.  Typical was to
debug code using FORTRAN G, then try to get it to work as well under
OPT=1.  If it was still too slow, you would start compiling things at
OPT=2 and fixing the things that broke.  Since the problems introduced
by OPT=2 were likely to show up somewhere else, it was handy to do it
this way to localize the problem.  (Where in this file do I reference
that common block?  Okay, here it is what are the other parameters?
Ah ha, an EQUIV!  Nope, that's not it...)

    But for large matrices and number theory work, the only way to go.
(PL-I had huge procedure call overhead.  You could design around it,
but then you might as well use FORTRAN.)

--

					Robert I. Eachus

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

Re: should I be interested in ada?

[Dan Nagle]

Hello,

Nick Roberts wrote:
> 
> Dan Nagle wrote in message <36CC6AC0.25DBE56D@erols.com>...
<snip requoted material>
 
> 'Raw floating point speed' is largely to do with the target architecture.
> Those speed-critical operations which are not hard-wired or micro-coded are
> carefully implemented in assembly. I don't believe there are any differences
> in the opportunities for optimisation between Ada and Fortran (e.g. Ada
> supports global variables, it just doesn't force them on you).

Does Ada enforce anti-aliasing rules regarding the global variables?

Do the Ada constructs which have been given as substitutes for
Fortran 95 array syntax have an implied order of operation?
I'll grant you that a modern programming language, Ada95 or
Fortran95 can define operators and assignments to mimic f95
array syntax.  Can Ada mimic f95 array _semantics_?  If I use
the Ada constructs, is there an implied order of evanualtion?
If I say

real, dimension( n, n) :: a, b    ! f95-speak for 2 nxn arrays of reals

and then say

a = b                             ! f95 array assignment

The order in which the assignments occur if unspecified.  Thus,
it may happen in parallel, or in _any_ order the compiler finds
most optimal.  Can any of the Ada constructs proposed deliver
the semantics of f95 array operations?

I really am simply courious.  I see many things in Ada which
I find attractive and I want to know about the optimization issues.
> 
> Thus, the high-level language is, theoretically, completely immaterial. Of
> course, in practice, you may well find Fortran compilers which have better
> written libraries and/or better optimisation. And, of course, for
> multi-processor targets, there are the (many!) parallelising Fortran
> compilers.

Unfortunately, autoparallelization is like automatic programming.
It's just not all that good.  Any reasonably competent programmer
can beat the best autoparallelizer by a substantial margin.  For truly
_scalable_ solutions, one usually resorts to message passing (via
mpi or pvm), and there simply are no automatic tools for using
them.
> 
> |I know Fortran fairly well, I'm learning Ada and like it so far.
> |Right now, if I had to fly, I'd like the airplane to be designed
> |in Fortran, with the fly-by-wire done in Ada.  Just trying to use
> |the right tool for the right job.
> 
> Fortran is very much a general-purpose language now. But my curiosity is
> piqued: for which part of flying an aeroplane would you consider Fortran to
> be the 'right tool for the job'?

Design.  Fortran's speed will let the design engineer use a finer
grid, which gives a better analysis, which makes for safer, quieter,
etc. ariplanes.
> 
> |Please feel free to enlighten me about Ada's optimization capabilities.
> 
> This is an issue which happens to be close to my heart. I would like someone
> to point out to me an optimisation that can be done in Fortran (or any other
> general purpose imperative language) which cannot be done in Ada. There may
> be such optimisations - I have an open mind - but I have never come across
> any yet.

I've tried to do that above.

<snip sig>

-- 

Cheers!
Dan Nagle		dnagle@erols.com

Re: should I be interested in ada?

[robert_dewar]

In article <36CD44CF.A61DAE96@erols.com>,
  dnagle@erols.com wrote:
> Hello,
>
> Does Ada enforce anti-aliasing rules regarding the global
> variables?

The anti-aliasing rules are in some respects weaker,
although in other respects stronger (the stronger typing
for example allows better aliasing information to be
built). You can construct artificial examples which give
a theoretical optimization advantage in either direction.
How important this is in practice is anyone's guess.


> Do the Ada constructs which have been given as
> substitutes for Fortran 95 array syntax have an implied
> order of operation? If I say
>
> real, dimension( n, n) :: a, b
>                ! f95-speak for 2 nxn arrays of reals
>
> and then say
>
> a = b          ! f95 array assignment
>
> The order in which the assignments occur if unspecified.

Actually here Ada has an advantage, it does not even
see the assignment of b to a as a "series of assignment"
in any sense, Rather it is an assignment of a composite
object, and yes of course the compiler is free to achieve
this in any manner it pleases.

However, other aggregate operations in Fortran that imply
parallelism may not be so easy to model in Ada.

> I really am simply courious.  I see many things in Ada
> which. I find attractive and I want to know about the
> optimization issues.

Nick proposed that "the high level language is
theoretically compltely immaterial [to the optimization
issue]", and that of course is completely wrong.

It is definitely the case that there are various
theoretical differences, but as always, the difficulty
with any optimization issues is knowing how much
difference it will make in practice, and that is
hard to know. Usually such theoretical differences
are swamped by other engineering issues, i.e. "other
things being equal" is a condition that is not  in
practice easy to meet.


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

Re: should I be interested in ada?

[Dan Nagle]

Hello,

robert_dewar@my-dejanews.com wrote:

Thanks for your reply.  This is exactly the kind of
discussion I was hoping for.
> 
> In article <36CD44CF.A61DAE96@erols.com>,
>   dnagle@erols.com wrote:
<snip discussion>
> 
> Actually here Ada has an advantage, it does not even
> see the assignment of b to a as a "series of assignment"
> in any sense, Rather it is an assignment of a composite
> object, and yes of course the compiler is free to achieve
> this in any manner it pleases.

Actually, that's the way Fortran sees the array, too.
The array is a "first class object", just as much a single
entity as any other.  Programming for high performance
has taught me to look at things at two levels simultaneously:
what the langauge says and means, and what's going on in
the hardware.  Of course, on scalar processors, things actually
happen element by element.

<snip further discussion and sig>

I like the built-in tasking in Ada, Fortran uses add-on libraries
to achieve the same thing.  Often vendor specific, and therefore
something of a nuiscance.

BTW, I found Barnes' Ada95 book at www.bookpool.com at a substantial
discount.  They're out of stock :-(, but I backordered.

That's 2 I owe this group.

-- 

Cheers!
Dan Nagle		dnagle@erols.com

Re: should I be interested in ada?

[Nick Roberts]

robert_dewar@my-dejanews.com wrote in message
<7ajrpu$jpq$1@nnrp1.dejanews.com>...
|> Does Ada enforce anti-aliasing rules regarding the global
|> variables?
|
|The anti-aliasing rules are in some respects weaker,
|although in other respects stronger (the stronger typing
|for example allows better aliasing information to be
|built). You can construct artificial examples which give
|a theoretical optimization advantage in either direction.
|How important this is in practice is anyone's guess.


However, I think there are ways in which an Ada compiler could 'get round'
the theoretical advantage that Fortran has (see my other post).

[...]
|However, other aggregate operations in Fortran that imply
|parallelism may not be so easy to model in Ada.


Certainly true, in terms of source text, there are some Fortran constructs
which are not so readily witten in Ada. For example (a simple one!):

   x(1:3,:,1:5) = y(:)

might have to be written in Ada as:

   for i in 1..3 loop
      for j in X'Range(2) loop
         for k in 1..5 loop
            X(i,j,k) := Y(j);
         end loop;
      end loop;
   end loop;

Not nearly so neat or convenient (but, nevertheless, not impractical).

However, an optimising Ada compiler targetting, say, a SIMD machine, would
still be able to vectorise the assignment. This is an 'obvious'
optimisation. For any target, there's no reason why it couldn't produce code
just as good as for the Fortran equivalent.

|> I really am simply courious.  I see many things in Ada
|> which. I find attractive and I want to know about the
|> optimization issues.
|
|Nick proposed that "the high level language is
|theoretically compltely immaterial [to the optimization
|issue]", and that of course is completely wrong.
|
|It is definitely the case that there are various
|theoretical differences, but as always, the difficulty
|with any optimization issues is knowing how much
|difference it will make in practice, and that is
|hard to know. Usually such theoretical differences
|are swamped by other engineering issues, i.e. "other
|things being equal" is a condition that is not  in
|practice easy to meet.


I should have avoided generalising to 'high level languages'. I don't
believe there is any _theoretical_ difference between Fortran 90 and Ada 95,
as regards optimisation. I agree entirely that _are_ differences, in
practice.

Can anyone provide an example (which isn't totally unrealistic?) which shows
an unavoidable optimisation advantage of one language over another?

-------------------------------------
Nick Roberts
-------------------------------------

Re: should I be interested in ada?

[Peter Hermann]

robert_dewar@my-dejanews.com wrote:
> Nick proposed that "the high level language is
> theoretically compltely immaterial [to the optimization
> issue]", and that of course is completely wrong.

This is well outlined in an article of Tartan's magazine
"On Target" vol2 #4 Spring 1995 pages 6-8 by David Syiek:
"C versus Ada: Arguing Performance Religion"

The article includes interesting benchmarks ;-)

I like to know whether this text could be reached electronically?

-- 
Peter Hermann Tel+49-711-685-3611 Fax3758 ica2ph@csv.ica.uni-stuttgart.de
Pfaffenwaldring 27 Raum 114, D-70569 Stuttgart Uni Computeranwendungen
http://www.csv.ica.uni-stuttgart.de/homes/ph/
Team Ada: "C'mon people let the world begin" (Paul McCartney)

Re: should I be interested in ada?

[Joel Seidman]

Nick Roberts wrote:
> 
> Jerry Petrey wrote in message <36CC11A1.C7A71642@hercii.mar.lmco.com>...
> [...]
> |> Fortran's array facilities as an example, in Fortran one can put:
> |>
> |>    real, dimension (1:10) :: x
> |>    ...
> |>    x = 1.0
> |>
> |> setting all the elements of x to 1.0 (a 'broadcast scalar'), whereas in
> Ada
> |> to do the same thing, you must code something like:
> |>
> |>    X: array (1..10) of Float;
> |>    ...
> |>    for i in X'Range loop X(i) := 1.0; end loop;
> |
> |
> |I think using an aggregate would be much better than a loop:
> |
> |X := (1 .. 10 => 1.0);
> 
> Precisely right, of course.
> 
Hmmmm. This raises a question about what "better" means. I have seen the
latter recommended for style, and it does read better to me. However,
when I applied this to large aggregates, stack utilization went throught
the roof. The compiler (VADS) created a temp and then moved it on top of
the target variable. I quickly learned to use this method only where the
aggregate couldn't be too large. I'm really not sure why VADS does this.
Is it typical of Ada compilers? Or was VADS failing to do a fairly
obvious optimization. (To be fair, this was an old version of VADS. I
haven't tried this with our current compiler.)

-- Joel

Re: should I be interested in ada?

[fraser]

I nearly cried when gpetrey@hercii.mar.lmco.com said:

>>    X: array (1..10) of Float;
>>    ...
>>    for i in X'Range loop X(i) := 1.0; end loop;

>I think using an aggregate would be much better than a loop:

>X := (1 .. 10 => 1.0);

In this situation, I usually use

   X := (others => 1.0);

to avoid a dependency on the array bounds.  In fact, one of my favourite
things about Ada is the various ways in which you can specify a range.
I generally pick the lowest one on the following list that's available
in the context:

   for I in 1 .. 10 loop
   for I in Low .. High loop
   for I in Discrete_Type loop
   for I in Array_Type'Range loop
   for I in Array_Object'Range loop

(I think I read this in the Quality and Style Guide).

Btw: I love the Fortran 90 'where' feature ... anything that avoids
looping over an array performing an identical operation on each element
has to be a Good Thing.

Fraser.
--
Fraser Wilson   |  700 East Middlefield Rd  |  Phone:  650 943 5270
Sr R&D Engineer |  Mountain View, CA 94043  |  Fax:    650 934 1227
Synopsys Inc    |  USA                      |  Email:  ^nospam^synopsys
           Ada, Linux, PowerPC: The Golden Triangle

Re: should I be interested in ada?

[Matthew Heaney]

fraser@nospam.com writes:

> In fact, one of my favourite things about Ada is the various ways in
> which you can specify a range.  I generally pick the lowest one on the
> following list that's available in the context:
> 
>    for I in 1 .. 10 loop
>    for I in Low .. High loop

Perhaps I'm being pedantic, but I don't recommend these forms.  It's
better to try to assert the type somehow.  I sometimes see this:

    for I in 1 .. 10 loop

        ... Array_Object (I) ...

    end loop;

but this makes me cringe.  Yes, I know the type of index I "defaults" to
Integer, but I'd rather you state that fact explicitly:

    for I in Positive range 1 .. 10 loop


If you use this technique, you avoid the esoterica like

    for I in -1 .. 10 loop

that wouldn't compile in Ada83.  Just do this instead:

   for I in Integer range -1 .. 10 loop

and all is well, no matter which version of the language you're using.

The only time I like to use the form

   for I in 1 .. 10 loop

is when I need to do some work that number of times, and I'm not
actually using index in the body of the loop.  Maybe a better choice of
loop index name is

   for Count in 1 .. 10 loop

to emphasize that this is not an array index.



>    for I in Discrete_Type loop
>    for I in Array_Type'Range loop
>    for I in Array_Object'Range loop

I like these better.

> (I think I read this in the Quality and Style Guide).

Well, yet another guideline in that book I disagree with.

Re: should I be interested in ada?

[fraser]

I nearly cried when matthew_heaney@acm.org said:

>fraser@nospam.com writes:

>> In fact, one of my favourite things about Ada is the various ways in
>> which you can specify a range.  I generally pick the lowest one on the
>> following list that's available in the context:
 
>>    for I in 1 .. 10 loop
>>    for I in Low .. High loop

>Perhaps I'm being pedantic, but I don't recommend these forms.  It's
>better to try to assert the type somehow.  I sometimes see this:

Maybe I was being unclear; what I mean was that the two forms above are
ones I don't use.  The top one in the list is the least preferred, the
bottom is the most preferred.

Using "Positive range 1 .. 10" instead as you suggest for the above
two forms is probably wise; however it's been an awful long time since
I wrote anything like that.  But there you go.

>>    for I in Discrete_Type loop
>>    for I in Array_Type'Range loop
>>    for I in Array_Object'Range loop

>I like these better.

>> (I think I read this in the Quality and Style Guide).

>Well, yet another guideline in that book I disagree with.

Actually, I think you agree with it -- I just said it badly.

cheers,
Fraser.
--
Fraser Wilson   |  700 East Middlefield Rd  |  Phone:  650 943 5270
Sr R&D Engineer |  Mountain View, CA 94043  |  Fax:    650 934 1227
Synopsys Inc    |  USA                      |  Email:  ^nospam^synopsys
           Ada, Linux, PowerPC: The Golden Triangle

Re: should I be interested in ada?

[Hartmut H. Schaefer]

> How many platforms have ada compilers (in principle AND in practice)?
> 
Since I'm employed at Rational I can tell you about which platforms are
supported by Apex, a Rational IDE for Ada and C++. Apex is available on all
major Unix platforms (SUN, DEC, IBM, HP, SGI) and Windows NT, see
http://www.rational.com/products/apex/prodinfo/index.jtmpl. When a new
release is issued usually the latest 2 host operating systems are
supported.

But there are also other compiler vendors like AONIX, GNAT, RR Software,
Green Hills, .... which might support other platforms.

> What are the main advantages/disadvantages of Fortran and Ada?

More info on Ada, e.g. why you might want to use Ada and a more complete
list of compiler vendors, you can find at http://www.adaic.org. The list of
compilers there is not necessarily complete. You probably want to contact
the various vendors directly for this info. 

Hartmut Schaefer

Re: should I be interested in ada?

[bill]

In article <01be5cd6$9c593000$b132e8c3@hup-pc>, "Hartmut says...
>
 
>Apex is available on all
>major Unix platforms (SUN, DEC, IBM, HP, SGI) and Windows NT, 

DO you mean Apex is NOT available on Linux??

Linux is a major Unix platform. And getting bigger every day. 

Bill.
 

Re: should I be interested in ada?

[dewar]

In article <7an3f5$nhi@drn.newsguy.com>,
  bill <bill@newsguy.com> wrote:

> Do you mean ... is NOT available on Linux??
>
> Linux is a major Unix platform. And getting bigger every
> day.
>
> Bill.

Note that GNAT is fully supported on Linux, and is indeed
a natural match (both are GPL'ed open source systems which
critically depend on the GNU infrastructure).

We have a number of serious commercial customers using the
supported version on Linux, and we see increased interest
in this platform every day. For GNAT, we consider Linux to
be one of our leading platforms.

Note that public versions of the supported GNAT ports,
including the Linux port, as well as some volunteer ports
for other systems, are freely available at multiple sites.

Robert Dewar
Ada Core Technologies

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

Re: should I be interested in ada?

[dewar]

In article <01be5cd6$9c593000$b132e8c3@hup-pc>,
  "Hartmut H. Schaefer" <Hartmut_Peg@compuserve.com> wrote:
> But there are also other compiler vendors like AONIX,
> GNAT, RR Software, Green Hills, .... which might support
> other platforms.

There is, to my knowledge, no Ada vendor called GNAT :-)

No doubt Helmut meant to say Ada Core Technologies. ACT
specializes in providing 100% complete implementations of
both native and cross-systems and is the only vendor that
can supply 100% complete implementations of Ada 95,
including all the optional annexes. These complete
implementations are available for many systems, including
all those that Helmut mentioned, as well as several others,
including x86 Linux, Alpha VMS, NT/Interix, x86 Solaris,
and OS/2. All these are fully supported by Ada Core
Technologies, check our web site (www.gnat.com) for
details.

In general good advice is to go check the Web sites of
all major Ada vendors. For a complete set of Ada vendor
names, see the list of validated compilers, also a useful
source of direct information.

The bottom line here is that good Ada 95 compilers are
available for virtually all commonly used systems. Note
that the lists above did not include cross systems, but
here too there are many choices (for example, VxWorks/PPC
is available from at least four vendors). On most, but
not all systems, multiple different compilers are available
from different vendors, allowing you to choose the one most
suitable for your use. Furthermore this level of
competition keeps the Ada 95 market lively, and all vendors
are constantly improving their offerings.

At this stage, availability of compilers is not an issue
in adopting Ada 95!

Robert Dewar
Ada Core Technologies

P.S. this is a bit close to an ad, I know, but it seemed
appropriate to respond to the Rational post, which was
also a bit close. The distinction between information and
advertisements is not always clear! Perhaps we should have
a kind of joint "advertisement FAQ", that would contain
such notes from all vendors :-) Perhaps the other vendors
will also provide similar posts, and we can put them all
together to make that FAQ entry!

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

Re: should I be interested in ada?

[dennison]

In article <7aniep$mam$1@nnrp1.dejanews.com>,
  dewar@gnat.com wrote:

> P.S. this is a bit close to an ad, I know, but it seemed
> appropriate to respond to the Rational post, which was
> also a bit close. The distinction between information and
> advertisements is not always clear! Perhaps we should have

Considering the question was about compiler availablity, I don't think such a
response is out of bounds at all.

T.E.D.

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