Ada vs Fortran for scientific applications
Nasser Abbasi
Fortran for scientific and number crunching type applications?
To make the discussion more focused, let's assume you want to start
developing a large scientific application in the domain where Fortran is
commonly used. Say you want to develop a new large Finite Elements Methods
program or large computational physics simulation system. Assume you can
choose either Ada or Fortran.
What are the technical language specific reasons why Fortran would be
selected over Ada?
I happened to know a little about Ada and Fortran, and from what I know, I
think Ada would be an excellent choice due to its strong typing, good
support for numerical types and good Math library.
I know also that Fortran is supposed to be better/faster when it comes to
working with large Arrays (Matrices), but it is not clear to me why that is,
and if it is still true with Ada 05. Something about arrays aliasing, but
not sure how that is.
I am also not sure on the support of sparse matrices in both languages'
libraries.
It is known that Ada strong domain is realtime and safety critical
applications. I never understood why Ada never became popular in the
scientific field in particular in areas such as computational physics or CFD
or such similar fields.
Any thoughts?
thanks,
Nasser
Brooks Moses
> I like to discuss the technical reasons why Ada is not used as much as
> Fortran for scientific and number crunching type applications?
>
> To make the discussion more focused, let's assume you want to start
> developing a large scientific application in the domain where Fortran is
> commonly used. Say you want to develop a new large Finite Elements Methods
> program or large computational physics simulation system. Assume you can
> choose either Ada or Fortran.
>
> What are the technical language specific reasons why Fortran would be
> selected over Ada?
In my case? I know Fortran. I don't know Ada. I would be foolish to
attempt to learn a new language while writing a large program that I
needed to rely on.
> I happened to know a little about Ada and Fortran, and from what I know, I
> think Ada would be an excellent choice due to its strong typing, good
> support for numerical types and good Math library.
Quite probably. Many languages are.
I'm rapidly becoming of the opinion that, once languages hit a minimum
level of functionality sufficient to be capable of solving the problem
at hand -- and, for scientific processing, that generally means "does it
avoid doing something stupid with basic array math?" and "can it link to
an appropriate parallel-processing library" -- the relevant questions
are all about the available programmers and the character of the
interface between the programmer and the language. Some languages are
vastly easier to program in than others -- but which one is which
depends on the programmers you have and what they're trying to do.
> I know also that Fortran is supposed to be better/faster when it comes to
> working with large Arrays (Matrices), but it is not clear to me why that is,
> and if it is still true with Ada 05. Something about arrays aliasing, but
> not sure how that is.
This may be true to a minor extent; I doubt that there is any major
fundamental difference. In general, "Which language is faster?" is a
meaningless question.
To take a well-populated example, consider that for Fortran on Intel
desktop computers there are usually significant variations (10 to 20
percent seems very common) in the speed of the exact same program when
compiled on different compilers -- and that's just the mature compilers.
With less-mature compilers, such as early versions of g95 and
gfortran, there can be differences of a factor of two or three in speed.
Now, it is highly unlikely that the Ada language has anything in it that
will cause more than a few percentage points of difference in the
maximum theoretically-achievable speed. Thus, in practice any speed
differences are going to be almost entirely a factor of the quality of
the code you write, and the quality of the compiler you compile it on.
The only way the language is likely to be relevant is if you are writing
the code for a platform where there aren't any high-quality compilers
for the language you're using. My completely unfounded guess is that
this is more likely to be true for Ada than it is for Fortran, simply
because of popularity, but it could be completely the reverse for the
system you're using.
Thus, it's far more important to look at the compilers you have
available, and do your own tests on comparable code similar to your
expected application, than it is to worry about minor theoretical
details about "which language is faster".
> I am also not sure on the support of sparse matrices in both languages'
> libraries.
I'd be fairly surprised if there weren't decent sparse matrix libraries
available for both languages. Probably lots of them, with a vast range
of quality.
> It is known that Ada strong domain is realtime and safety critical
> applications. I never understood why Ada never became popular in the
> scientific field in particular in areas such as computational physics or CFD
> or such similar fields.
I have no idea; by the time I reached college, that popularity contest
had already been settled, and my intro-to-engineering class taught
Fortran and didn't teach Ada.
- Brooks, posting from comp.lang.fortran
--
The "bmoses-nospam" address is valid; no unmunging needed.
Dmitry A. Kazakov
> What are the technical language specific reasons why Fortran would be
> selected over Ada?
Languages are *never* selected by technical reasons. They are by political
ones.
[...]
> Any thoughts?
Main strength of Ada for scientific applications is in my view its safety.
I am writing a lot for AI and image processing. In both cases debugging is
practically impossible. When something does not work or just looks not
working, how do you know, is it an algorithmic problem or a software bug?
There are techniques which prevent much bugs through a disciplined software
developing process. But these are extremely expensive, require tools,
man-power, requirements analysis, much time, everything poor scientists
usually do not have...
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
Greg Lindahl
Nasser Abbasi <n...@12000.org> wrote:
>I like to discuss the technical reasons why Ada is not used as much as
>Fortran for scientific and number crunching type applications?
I'm not sure that technical reasons are involved in the actual
decision making. BTW, cross-posting a question like this often
results in poor discussion.
-- greg
Jan Vorbrüggen
> will cause more than a few percentage points of difference in the
> maximum theoretically-achievable speed. Thus, in practice any speed
> differences are going to be almost entirely a factor of the quality of
> the code you write, and the quality of the compiler you compile it on.
That might be the case for Ada, but it's not clearly true for others.
A language - any language, but in particular a computer or programming
language - has both syntax and semantics. In trying to evaluate a language,
people too often only look at the syntax - how can I express an operation
I want executed? - instead of primarily the semantics - what in detail does
"operation" mean here? -. If a language does not allow you to express cer-
tain things that you know to be true about your operation, and that could
be used to optimize the program, you are already at a disadvantage compared
to a different language where that is not the case. As an example, look at
the semantics of a DO loop and the apparantly equivalent FORALL statement
in Fortran.
Jan
Tim Prince
Following contains some personal opinions formed by reading about it,
not by actual comparison of functionality, which has seldom been possible:
If the design goals of Ada had been fully realized, the major advantage
of Ada would have been built-in support for multi-processing. f2008
intends to make up for that, in the most relevant case, with co-arrays.
Add-ons like OpenMP and MPI have kept Fortran ahead, for practical
purposes. The additional difficulty of learning sufficient Ada and
finding an efficient compiler, and increased difficulty of development,
have served to restrict it to the application domains most directly
targeted and financed.
Michael Metcalf
"Brooks Moses" <bmoses...@cits1.stanford.edu> wrote in message
news:44715DED...@cits1.stanford.edu...
>
>> It is known that Ada strong domain is realtime and safety critical
>> applications. I never understood why Ada never became popular in the
>> scientific field in particular in areas such as computational physics or
>> CFD or such similar fields.
>
> I have no idea; by the time I reached college, that popularity contest had
> already been settled, and my intro-to-engineering class taught Fortran and
> didn't teach Ada.
>
If I recall correctly, ADA has no complex arithmetic capability, a killer
for those who need it.
Regards,
Mike Metcalf
Dr. Adrian Wrigley
Annex G (Numerics) of Ada 95 specifies complex arithmetic and I/O.
It's only been around for eleven years...
--
Adrian
George N. White III
> I like to discuss the technical reasons why Ada is not used as much as
> Fortran for scientific and number crunching type applications?
>
> To make the discussion more focused, let's assume you want to start
> developing a large scientific application in the domain where Fortran is
> commonly used. Say you want to develop a new large Finite Elements Methods
> program or large computational physics simulation system. Assume you can
> choose either Ada or Fortran.
Such a project requires signficant resources, so the decision isn't up to
the individuals who will do the work. Managers will ask questions like:
1. if the lead programmer gets killed riding her motorcycle when the
project is 95% complete, who can I find to finish the job?
2. the project needs to remain useful for 20-30 years. Which compiler
has a 30-year track record?
With questions like this, Ada would have to offer really signficant
benefits to be chosen over Fortran, but the answers also depend on the
organization. Some organizations foster a structure where no one
individual is irreplaceable, and would expect any of the programmers to
be able to take the place of a fallen colleague. Some organizations don't
simply consume tools, but treat them as a resource that must be maintained
and nourished. An organization that embrasses Ada to the point that they
employ people who participate in standards activities and provide a
resource to the internal developer community will not give as much weight
to Fortran's historical record.
If you take the long term view, you should also ask: will the organization
still be around in 30 years?
--
George N. White III <aa...@chebucto.ns.ca>
Jean-Pierre Rosen
> What are the technical language specific reasons why Fortran would be
> selected over Ada?
>
1) Packaging. Packages allow better organization of software, which is
good for any kind of application.
2) Strong typing. Scientific applications often deal with physical
units, and Ada is great at supporting these.
3) User defined accuracy. Ada allows you to define the accuracy you
need, the compiler chooses the appropriate representation. Note that you
are not limited to only two floating point types (many machines have
more than that).
4) Fixed points. Not available in Fortran
5) Guaranteed accuracy, not only for basic arithmetic, but for the whole
mathematical library
6) Standardization. All compilers process exactly the same language.
7) Interfacing. Easy to call libraries in foreing languages => all
libraries available for Fortran are available for Ada.
8) Concurrency, built into the language
9) Generics. Stop rewriting these damn sorting routines 1000 times.
10) Default parameters. Makes complex subprograms (simplex...) much
easier to use.
11) Operators on any types, including arrays. Define a matrix product as
"*"...
12) Bounds checking, with a very low penalty. Makes bounds checking
really usable.
--
---------------------------------------------------------
J-P. Rosen (ro...@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr
Dan Nagle
Jean-Pierre Rosen wrote:
> Nasser Abbasi a écrit :
>> What are the technical language specific reasons why Fortran would be
>> selected over Ada?
>>
> Some immediate reasons:
> 1) Packaging. Packages allow better organization of software, which is
> good for any kind of application.
Can you compare and contrast Ada packages
with Fortran modules and submodules?
> 2) Strong typing. Scientific applications often deal with physical
> units, and Ada is great at supporting these.
What specific features of Ada provide better support
than the comparable feature of Fortran?
> 3) User defined accuracy. Ada allows you to define the accuracy you
> need, the compiler chooses the appropriate representation. Note that you
> are not limited to only two floating point types (many machines have
> more than that).
How is this better than Fortran's kind mechanism?
> 4) Fixed points. Not available in Fortran
Agreed. How important is this for floating point work?
Fortran is rarely used for imbedded software (at least,
I wouldn't).
> 5) Guaranteed accuracy, not only for basic arithmetic, but for the whole
> mathematical library
Can you compare Ada's accuracy requirements with Fortran's
support for IEEE 754?
> 6) Standardization. All compilers process exactly the same language.
Again, how is this different? Fortran compilers are required
to be able to report use of extensions to the standard.
> 7) Interfacing. Easy to call libraries in foreing languages => all
> libraries available for Fortran are available for Ada.
Can you compare Interfaces.C to ISO_C_BINDING?
How is one better or worse than the other?
> 8) Concurrency, built into the language
Co-arrays and concurrent loops are coming in Fortran 2008.
> 9) Generics. Stop rewriting these damn sorting routines 1000 times.
Intelligent Macros are coming in Fortran 2008.
> 10) Default parameters. Makes complex subprograms (simplex...) much
> easier to use.
Agreed.
> 11) Operators on any types, including arrays. Define a matrix product as
> "*"...
How is Ada's operators for types better or worse than Fortran's?
Is Ada's "*" operator better than Fortran's matmul()?
> 12) Bounds checking, with a very low penalty. Makes bounds checking
> really usable.
How is Ada's bounds checking better or worse than Fortran's?
"Fortran" /= "FORTRAN 77" ;-)
--
Cheers!
Dan Nagle
Purple Sage Computing Solutions, Inc.
Nasser Abbasi
"Dan Nagle" <dann...@verizon.net> wrote in message
news:tHkcg.6937$kR6.484@trnddc05...
>> 11) Operators on any types, including arrays. Define a matrix product as
>> "*"...
>
> How is Ada's operators for types better or worse than Fortran's?
> Is Ada's "*" operator better than Fortran's matmul()?
>
I'll answer the easy one for now since I have not had my coffee yet:
It is clear that
A*B
is easier to read and understand than
MATMUL(A,B)
would you not agree?
>
> "Fortran" /= "FORTRAN 77" ;-)
>
Yes :), I was surprised to read that now FORTRAN is called Fortran, (only
one letter is uppercase). This is progress (I think).
Nasser
Jan Vorbrüggen
>
> A*B
>
> is easier to read and understand than
>
> MATMUL(A,B)
>
> would you not agree?
I definitely disagree. Is that operator meant as the matrix multiplication,
the outer product, element-wise multiplication, or something else that has
the mathematical properties of a group?
Jan
Richard E Maine
> Again, how is this different? Fortran compilers are required
> to be able to report use of extensions to the standard.
Only syntactic extensions. See 1.4(3) of f2003, which I presume is the
requirement you are talking about. Or perhaps you are also including
1.4(6). In any case, the requirements are very specific. Fortran
compilers are not required to, and many don't, have the capability to
report on *all* extensions, where I emphasize the "all". Let me
remphasize it by explicitly stating that "all" includes extensions for
things come up only at run-time. I'm not sure that a single Fortran
compiler exists that has the capability of reporting the use of *all*
extensions. It is my possibly flawed understanding that this is
fundamentally different from the situation for Ada.
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
Gordon Sande
>
> "Dan Nagle" <dann...@verizon.net> wrote in message
> news:tHkcg.6937$kR6.484@trnddc05...
>
>>> 11) Operators on any types, including arrays. Define a matrix product as "*"...
>>
>> How is Ada's operators for types better or worse than Fortran's?
>> Is Ada's "*" operator better than Fortran's matmul()?
>>
>
> I'll answer the easy one for now since I have not had my coffee yet:
>
> It is clear that
>
> A*B
But the Hadamard product is not the same as a matrix product.
Conventions and understandability do matter.
Dan Nagle
Nasser Abbasi wrote:
<snip>
> I'll answer the easy one for now since I have not had my coffee yet:
>
> It is clear that
>
> A*B
>
> is easier to read and understand than
>
> MATMUL(A,B)
It is? All the intrinsic operators in Fortran apply
element-wise, and * is no exception. How does that make
the intrinsic procedure harder to read?
The applications programmer may always define a matrix type,
and define the * operator to be the matmul intrinsic.
Note the distinction between "rank-2 array" and "matrix".
<snip>
> I was surprised to read that now FORTRAN is called Fortran, (only
> one letter is uppercase). This is progress (I think).
I think Fortran and Ada have a lot in common,
both are being actively developed (though not on the same schedule).
And both are threatened by the "I only know C++, it's the best language"
syndrome. :-( And, I think, both are superior technical solutions
within their respective problem domains. Although Eiffel interests
me also.
Paul Van Delst
> "Dan Nagle" <dann...@verizon.net> wrote in message
> news:tHkcg.6937$kR6.484@trnddc05...
>
>
>>>11) Operators on any types, including arrays. Define a matrix product as
>>>"*"...
>>
>>How is Ada's operators for types better or worse than Fortran's?
>>Is Ada's "*" operator better than Fortran's matmul()?
>>
>
> I'll answer the easy one for now since I have not had my coffee yet:
>
> It is clear that
> A*B
> is easier to read and understand than
> MATMUL(A,B)
> would you not agree?
Hello,
At the risk of igniting a language war (not my intent) and/or exposing my ignorance of
Ada, I find the former misleading. To me, A*B suggests a regular old multiplication of two
arrays, rather than a matix multiplication. MATMUL(A,B) is definitely wordier but the
intent is quite clear.
Sufficient exposure is enough to adapt to the Ada meaning of A*B, but you specifically
mentioned one as clearly easier to read and understand .... so I'm tossing in my 2cents
worth. :o)
If I had my druthers wrt succinctness, I'd use a different operator for matrix
multiplication. Sort of like IDL where
A#B
or
A##B
signifies matrix multiplication (the two forms are, essentially, to avoid unnecessary
transposing of the second matrix.)
(I'm sure there's myriad reasons why a different operator is a bad idea.)
cheers,
paulv
>>"Fortran" /= "FORTRAN 77" ;-)
>>
> Yes :), I was surprised to read that now FORTRAN is called Fortran, (only
> one letter is uppercase). This is progress (I think).
>
> Nasser
>
>
>
>
--
Paul van Delst Ride lots.
CIMSS @ NOAA/NCEP/EMC Eddy Merckx
Ph: (301)763-8000 x7748
Fax:(301)763-8545
Brooks Moses
I agree, in principle -- and you've stated it rather more clearly that I
was able to; much of that is something that I meant to say and didn't
really.
My contention is that, in practice, most of the languages that numerical
code is commonly written in have semantics that are sufficient to do the
task reasonably well. And that as such, once one passes a certain bar
of functionality for the task, semantics have rather little impact on
the decision -- things like the distinction between a DO loop and an
equivalent FORALL construct rarely seem to have a significant impact.
(This does, though, require that one get past that bar, and a lot of
languages don't, usually because that's not what they're intended for.)
I should note, though, that I'm drawing the syntax/semantics line way
over on the side of semantics. For instance, I consider complex
arithmetic and multidimensional arrays to be essentially syntax -- one
can trivially write code longhand to produce the same functionality.
It's just awfully inefficient syntax.
On the other hand, I suspect that my view is colored pretty heavily from
not having a lot of parallel-processing experience, and that semantics
aren't anywhere near a most-of-the-top-languages-are-equivalent ceiling
there. Thus, I should probably limit my above claims to single-threaded
programs -- which I recognize is a significant limitation.
- Brooks
Ken Plotkin
>I'm not sure that technical reasons are involved in the actual
>decision making. BTW, cross-posting a question like this often
>results in poor discussion.
I think you're correct about that. ADA was very political.
As I recall, ADA was designed by the US DOD for use in embedded
systems. It came at a time when Pascal-like languages were in vogue.
Its structured nature and verbosity were intended to improve
readibility, maintenance and reliability.
I once needed an algorithm for radar processing. I received it in the
form of a snippet of ADA source code. If that snippet was
representative, it certainly achieved the readibility goal.
DOD put one major restriction that IMHO hurt ADA's acceptance. That
was that there were to be no subsets. To be called ADA it had to be a
full implementation. I believe it also had to pass quality control.
Compilers were expensive. In the 80s, when PCs were really catching
on, an ADA compiler for a PC cost several thousand dollars, vs a few
hundred for a Fortran compiler. I always figured the all-or-nothing
and testing requirements caused that.
Ken Plotkin
blm...@myrealbox.com
Ken Plotkin <kplo...@nospam-cox.net> wrote:
>On 22 May 2006 00:36:11 -0700, lin...@pbm.com (Greg Lindahl) wrote:
>
>>I'm not sure that technical reasons are involved in the actual
>>decision making. BTW, cross-posting a question like this often
>>results in poor discussion.
>
>I think you're correct about that. ADA was very political.
"Ada", is it not? The language's name is not an acronym, but is
a reference to Ada Lovelace, as I understand it.
A nitpick, admittedly.
[ snip ]
--
| B. L. Massingill
| ObDisclaimer: I don't speak for my employers; they return the favor.
Ken Plotkin
<blm...@myrealbox.com> wrote:
>"Ada", is it not? The language's name is not an acronym, but is
>a reference to Ada Lovelace, as I understand it.
You are correct.
>A nitpick, admittedly.
Nope - an important clarification. Thanks.
news.hinet.net
does it mean which syntax is suitable for scientific application?
if you mean it, you didn't waiting for fortan "2008" .
matlab may be another good choose.
.
It's good for scientific application.
why?
there are over 30+ math library .
simple syntax is easy to learn and writing.
high performance, it utilize fortran's math library and kernel is writing
in C and fortran.
a lot of language interfaces , such as java , c , fortran , and ada (ada is
especial in realtime and simulink).
you can call those language directly.
can translate to C code.
built-in complex type support.
It has operator overloading.
you can do mult(a,b,...) or a .* b .* ...
or matix Multiplies mmult(a,b...) or a * b *....
using vectorization. you almost can reduce most loop syntax in your code
more detail sse
http://www.mathworks.com/
of course,
there are some disadvantages.
weak type checking often causes errors in runtime. It almost never happens
in ada.
hard to read but easy to wirte. (writing is happy and read is painful)
In scientific application, It should be better than ada and fortan
^__^.
"Dan Nagle" <dann...@verizon.net> ???????:tXlcg.3832$p13.2487@trnddc07...
Tim Prince
> On the other hand, I suspect that my view is colored pretty heavily from
> not having a lot of parallel-processing experience, and that semantics
> aren't anywhere near a most-of-the-top-languages-are-equivalent ceiling
> there. Thus, I should probably limit my above claims to single-threaded
> programs -- which I recognize is a significant limitation.
>
As a major claim to superiority for Ada lies in its built-in support for
concurrency, the parallel capabilities acquired by Fortran must be
compared, according to the topic opened here.
Gareth Owen
> At the risk of igniting a language war (not my intent) and/or exposing
> my ignorance of Ada, I find the former misleading. To me, A*B suggests
> a regular old multiplication of two arrays, rather than a matix
> multiplication.
I think assuming anything about A*B is extremely dangerous. Just of
the top of my head, Ada and Matlab think it means matrix
multiplication and Fortran and Mathematica think its pointwise
multiplication.
It means basically nothing in C, and in C++ it means whatever the
matrix class implementor wanted it to mean.
Martin Krischik
Honest truth: For a user defined type - in Ada - * means whatever the
programmer wants it to mean. iE. unary + is often (mis)used as a
shorthand for type conversion.
In that respect Ada is not better then any other language with user
defined operators.
But then: you can allways define a Matrix_Multiplication (...) function
as well.
Martin
Jon Harrop
> Languages are *never* selected by technical reasons.
I select my languages for technical reasons.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/ocaml_for_scientists/chapter1.html
Jon Harrop
> Nasser Abbasi wrote:
>> What are the technical language specific reasons why Fortran would be
>> selected over Ada?
>
> In my case? I know Fortran. I don't know Ada. I would be foolish to
> attempt to learn a new language while writing a large program that I
> needed to rely on.
That's a great way to learn a new language.
gautier...@hotmail.com
# I like to discuss the technical reasons why Ada is not used as much
as
# Fortran for scientific and number crunching type applications?
The main reason is:
- Fortran started in 1953
- Ada started in 1983
During the 30 years before Ada *tons* of scientific software were done
and the Fortran compiler technology probabily still has a solid advance
over the "newcomers" in terms of numerical efficiency.
Generations of scientifics and engineers learned and then taught the
language.
Add to it that Fortran is readable and fully bracketed, which makes it
*on that point* as good as Ada.
# To make the discussion more focused, let's assume you want to start
# developing a large scientific application in the domain where Fortran
is
# commonly used. Say you want to develop a new large Finite Elements
Methods
# program or large computational physics simulation system. Assume you
can
# choose either Ada or Fortran.
If you have to program from scratch your FEM/CFD program, I suggest Ada
(successful experience); but most of the time projects will reuse
existing code, then, it depends...
The advantages of transition to Ada appear not immediately: probabily
you'll have to interface to Fortran routines, which is easy but not as
easy as not having to interface.
Only then the advantages begin to appear:
- the compiler finds plenty of nasty bugs, including in "established"
pieces of Fortran code you pass through f2a
- you prevent lots of bugs like bad element numbering by using
subtypes of Integer (Positive, arrays' ranges)
- you add much clarty by using enumerated types for coding boundary
conditions, methods, formats, options, etc. and let the compilation of
"case" statement find forgotten cases
- you can use the same code on several machines (no language dialect,
compatible I/O, you can select floating-point type in one "subtype Real
is ..." for the whole project)
- you can use the same code for filling several matrix types (sparse,
band) through generics
A few other advantages may have been levelled in Fortran 9x+,
eventually by breaking compatibility with previous versions - please
comment!
- you prevent bugs and add readbility with "for i in A'Range(1) loop"
and not having to pass dimensions as parameters
- no possibility of bugs like passing matrix,vector instead of
vector,matrix as parameters and other type mismatches
- no problem like real_variable = (integer expression) putting fuzzy
contents as floating-point data
- no problem of undefined variables (ijk written as jik): Ada has an
implicit overall "implicit none"
- no need of explaining for each subroutine parameter its dimensions
and base type (Ada has user-defined types)
- no problem with several formats for floating-point litterals (1.3e7,
4.2d5)
IMHO all advantages concern essentially reliability and and an
important programmer-time reduction.
Gautier
______________________________________________________________
Ada programming -- http://www.mysunrise.ch/users/gdm/gsoft.htm
NB: For a direct answer, e-mail address on the Web site!
Jan Vorbrüggen
> over on the side of semantics. For instance, I consider complex
> arithmetic and multidimensional arrays to be essentially syntax -- one
> can trivially write code longhand to produce the same functionality.
> It's just awfully inefficient syntax.
No, that assumption is incorrect. To take complex arithmetic as an example:
If I have a native complex type, the language implementor is free to arrange
the real and imaginary part in memory as he sees fit, perhaps even using
different arrangements in different situations. She can easily make use of
other pieces of information, for instance that one of the parts is zero or
one, to simplify an arithmetic expression (think of constant propagation
and elimination of common subexpressions). If you do not have the semantics
available, you are forced into a particular implementation that will likely
by suboptimal in all but a set of measure 0 8-). This is very similar to
using a non-SEQUENCE derived type versus a C structure: The _programmer_
may assume _less_ about what is going on under the hood, has to specify
less details, and therefore the implementor has more freedom to select a
(we hope) optimal solution.
> On the other hand, I suspect that my view is colored pretty heavily from
> not having a lot of parallel-processing experience, and that semantics
> aren't anywhere near a most-of-the-top-languages-are-equivalent ceiling
> there. Thus, I should probably limit my above claims to single-threaded
> programs -- which I recognize is a significant limitation.
That is one of the clear distinctions for defining semantics of language,
and I agree you'll see a large difference in such cases. Nonetheless, even
for a single-threaded programme, there will be distinctions - see above.
Jan
Jean-Pierre Rosen
I am an Ada guy. FORTRAN was my first programming language, but it was
long, long ago, and I don't know about the latest improvements to the
language. I'll answer some questions here, but I'd like to be
enlightened on the latest trade from the FORTRAN side.
Dan Nagle a écrit :
> Hello,
>
> Jean-Pierre Rosen wrote:
>> Nasser Abbasi a écrit :
>>> What are the technical language specific reasons why Fortran would be
>>> selected over Ada?
>>>
>> Some immediate reasons:
>> 1) Packaging. Packages allow better organization of software, which is
>> good for any kind of application.
>
> Can you compare and contrast Ada packages
> with Fortran modules and submodules?
Honestly, I don't know about Fortran modules.
>> 2) Strong typing. Scientific applications often deal with physical
>> units, and Ada is great at supporting these.
>
> What specific features of Ada provide better support
> than the comparable feature of Fortran?
Is it possible in Fortran to define three *incompatible* types Length,
Time, and Speed, and define a "/" operator between Length and Time that
returns Speed?
>> 3) User defined accuracy. Ada allows you to define the accuracy you
>> need, the compiler chooses the appropriate representation. Note that
>> you are not limited to only two floating point types (many machines
>> have more than that).
>
> How is this better than Fortran's kind mechanism?
I need to be educated about Fortran's kind, but can you use it to
specify that you want a type with guaranteed 5 digits accuracy?
>> 4) Fixed points. Not available in Fortran
>
> Agreed. How important is this for floating point work?
> Fortran is rarely used for imbedded software (at least,
> I wouldn't).
It's not important for floating point work, it's important for fixed
point work :-)
Because Fortran has no fixed points, the scientific community sees
floating point as the only way to model real numbers. Actually, fixed
points have nothing to do with embedded software, they are a different
way of modelling real (in the mathematical sense) numbers, with
different numerical properties. Depending on the problem, fixed point
may (or not) be more appropriate.
>> 5) Guaranteed accuracy, not only for basic arithmetic, but for the
>> whole mathematical library
>
> Can you compare Ada's accuracy requirements with Fortran's
> support for IEEE 754?
Ada's accuracy requirement is independent from any hardware (or
software) implementation of floating points, and are applicable even for
non IEEE machines.
>> 6) Standardization. All compilers process exactly the same language.
>
> Again, how is this different? Fortran compilers are required
> to be able to report use of extensions to the standard.
AFAIK, there is a formal validation suite for Fortran, but
1) Compilers rarely report their validation result
2) A compiler is deemed "passed" if it succeeds 95% of the tests, while
100% is required for Ada
>> 7) Interfacing. Easy to call libraries in foreing languages => all
>> libraries available for Fortran are available for Ada.
>
> Can you compare Interfaces.C to ISO_C_BINDING?
> How is one better or worse than the other?
Sorry, I don't know what you are refering to (except for Interfaces.C :-)
>> 8) Concurrency, built into the language
>
> Co-arrays and concurrent loops are coming in Fortran 2008.
Concurrency has been in Ada since 1983! Moreover, it's a multi-tasking
model, not concurrent statements model. Both models have benefits and
drawbacks, it depends on the needs.
>
>> 9) Generics. Stop rewriting these damn sorting routines 1000 times.
>
> Intelligent Macros are coming in Fortran 2008.
I don't know what an "intelligent macro" is, but certainly generics
(once again available since 1983"), are much more than macros, even
intelligent ones.
For one thing, the legality of generics is checked when the generic is
compiled. This means that, provided actual parameters meet the
requirements of the formals, there is no neeed to recheck at
instantiation time, and ensures that any legal instantiation will work
as expected. AFAIK, this cannot be achieved by macros.
>> 10) Default parameters. Makes complex subprograms (simplex...) much
>> easier to use.
>
> Agreed.
>
>> 11) Operators on any types, including arrays. Define a matrix product
>> as "*"...
>
> How is Ada's operators for types better or worse than Fortran's?
> Is Ada's "*" operator better than Fortran's matmul()?
More convenient to write:
Mat1 := Mat2 * Mat3;
>> 12) Bounds checking, with a very low penalty. Makes bounds checking
>> really usable.
>
> How is Ada's bounds checking better or worse than Fortran's?
I may miss something on the Fortran side, but Ada's very precise typing
allows to define variables whose bounds are delimited. If these
variables are later used to index an array (and if the language features
are properly used), the compiler statically knows that no out-of-bound
can occur. In short, most of the time, an Ada compiler is able to prove
that bounds checking is not necessary, and corresponding checks are not
generated.
In practice, compiling an Ada program with or without bounds checking
shows very little difference in execution speed, because only the really
useful checks are left, all the spurious ones have been eliminated.
Dan Nagle
Jean-Pierre Rosen wrote:
> Disclaimer:
> I am an Ada guy. FORTRAN was my first programming language, but it was
> long, long ago, and I don't know about the latest improvements to the
> language. I'll answer some questions here, but I'd like to be
> enlightened on the latest trade from the FORTRAN side.
Little things first: I write Ada, you write Fortran.
> Dan Nagle a écrit :
<snip>
>> Can you compare and contrast Ada packages
>> with Fortran modules and submodules?
> Honestly, I don't know about Fortran modules.
Metcalf, Reid & Cohen, _Fortran 95/2003 Explained_ is a great place
to start. (I have Barnes for Ada 95, the Ada 2005 book
is back-ordered until summer :-( )
<snip>
> Is it possible in Fortran to define three *incompatible* types Length,
> Time, and Speed, and define a "/" operator between Length and Time that
> returns Speed?
Yes.
<snip>
> I need to be educated about Fortran's kind, but can you use it to
> specify that you want a type with guaranteed 5 digits accuracy?
Yes.
<snip>
> Ada's accuracy requirement is independent from any hardware (or
> software) implementation of floating points, and are applicable even for
> non IEEE machines.
These days, computers use 754 arithmetic (and if 754r finally completes,
I expect 754r arithmetic will follow eventually). The Fortran
committees are tracking 754r. Fortran isn't usually used for embedded
systems with "interesting" floating point.
<snip>
>> Can you compare Interfaces.C to ISO_C_BINDING?
>> How is one better or worse than the other?
> Sorry, I don't know what you are refering to (except for Interfaces.C :-)
iso_c_binding is the standard-defined module providing Fortran
definitions of C entities. It's about 95%
of Fortran's "Interoperability with C" feature.
<snip>
> Concurrency has been in Ada since 1983! Moreover, it's a multi-tasking
> model, not concurrent statements model. Both models have benefits and
> drawbacks, it depends on the needs.
Co-arrays are the main concurrency of f08. For a quick update,
the paper is at Rutherford-Appleton Labs, see
http://epubs.cclrc.ac.uk/bitstream/161/raltr-1998060.pdf
<snip>
> More convenient to write:
> Mat1 := Mat2 * Mat3;
A programmer may define a matrix type where the * may be
the matrix multiplication operator. This has been discussed
a bit in this thread.
<snip>
> In practice, compiling an Ada program with or without bounds checking
> shows very little difference in execution speed, because only the really
> useful checks are left, all the spurious ones have been eliminated.
In practice, bounds checking is available with every Fortran compiler.
It's usually off by default (for performance).
Fortran has not been f77 for 15 years now, modern Fortran is so
different some purists like to pretend it's a different language. :-)
Dr. Adrian Wrigley
>> Concurrency has been in Ada since 1983! Moreover, it's a multi-tasking
>> model, not concurrent statements model. Both models have benefits and
>> drawbacks, it depends on the needs.
>
> Co-arrays are the main concurrency of f08. For a quick update,
> the paper is at Rutherford-Appleton Labs, see
> http://epubs.cclrc.ac.uk/bitstream/161/raltr-1998060.pdf
I don't see that Ada concurrency and co-arrays have much relationship
at all. In an Ada program, you can:
Have several tasks performing computation
Have other tasks controlling GUIs, monitoring progress etc.
Have another task serving http requests etc.
And tasks can be split between several (possibly heterogenous) machines
in a network which may be added, fail or be removed.
Can you do implement this kind of concurrency just using
normal Fortran language features?
Isn't this a bit more like MPI?
In Ada, these concurrency features are very robust and streamlined.
This is because tasking was a primary goal of the language design.
For a typical Fortran application like weather forecasting, this
is exactly the architecture you might choose. It may be
hardcore numerical code. But technically, it is still real-time.
The Fortran mind-set still seems very "batch-oriented".
--
Adrian
Greg Lindahl
Jan Vorbrüggen <jvorbr...@not-mediasec.de> wrote:
>If I have a native complex type, the language implementor is free to arrange
>the real and imaginary part in memory as he sees fit,
Although Fortran does restrict the implementation, so the langauge
implementer is not fully free.
-- greg
Nasser Abbasi
publish a version of the Numerical recipes book in Ada.
I have been waiting for this for long time.
This should show the advantages of using Ada for scientific/numerical
applications.
If we can have the numerical recipes book in C,C++,Pascal, F77 and F90 for
crying out loud, why can't we have it in Ada?
(I do not know how anyone in their right mind would think that writing
numerical applications in C or even C++ would be better/more robust than in
Ada.... but I digress here)
Nasser
Michael Metcalf
"Nasser Abbasi" <n...@12000.org> wrote in message
news:YaEcg.91032$dW3....@newssvr21.news.prodigy.com...
>I personally think that one way to make Ada popular for scientific use is
>to publish a version of the Numerical recipes book in Ada.
>
> I have been waiting for this for long time.
>
> This should show the advantages of using Ada for scientific/numerical
> applications.
>
> If we can have the numerical recipes book in C,C++,Pascal, F77 and F90 for
> crying out loud, why can't we have it in Ada?
>
judged to be that large. The suggestion to do a f90 version fell on fertile
ground because a) f90 was clearly better than f77 and b) one of the team was
already heavily involved in Thinking Machines' version Fortran, which was
quite close to the f90 array language. In the right place at the right time.
Regards,
Mike Metcalf
Rich Townsend
My stance on A*B is this: if A*B denotes matrix multiplication, then A/B should
denote matrix 'division': B^-1*A. Which means you need to standardize matrix
inversion/linear-equations solution into the language. Which is batshit crazy.
cheers,
Rich
beli...@aol.com
> I personally think that one way to make Ada popular for scientific use is to
> publish a version of the Numerical recipes book in Ada.
>
> I have been waiting for this for long time.
>
> This should show the advantages of using Ada for scientific/numerical
> applications.
You cannot do this unless you get the authors of Numerical Recipes on
board, which would probably be difficult. I think a literal translation
of their Fortran or C code to Ada could not be posted online without
their permission.
The GNU Scientific Library (written in C)
http://www.gnu.org/software/gsl/ is open source. You could write an
open source version in Ada.
Pascal Obry
> As I recall, ADA was designed by the US DOD for use in embedded
> systems. It came at a time when Pascal-like languages were in vogue.
Not exactly. The requirements came from the DOD but the design was part
of an international call. The "winner" language was the green language
(Ada), it was designed at CII Honeywell Bull by a team lead by Jean Ichbiah.
> Its structured nature and verbosity were intended to improve
> readibility, maintenance and reliability.
Yep, Ada mains goals.
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
Dan Nagle
Dr. Adrian Wrigley wrote:
<snip>
> Isn't this a bit more like MPI?
Well, it's like MPI minus the rubbish.
> In Ada, these concurrency features are very robust and streamlined.
> This is because tasking was a primary goal of the language design.
>
> For a typical Fortran application like weather forecasting, this
^^^^
> is exactly the architecture you might choose. It may be
> hardcore numerical code.
I'm not sure which antecedent "this" references,
but the meteorological folks are one of the main
forces behind co-arrays.
Dick Hendrickson
Jean-Pierre Rosen wrote:
> Disclaimer:
> I am an Ada guy. FORTRAN was my first programming language, but it was
> long, long ago, and I don't know about the latest improvements to the
> language. I'll answer some questions here, but I'd like to be
> enlightened on the latest trade from the FORTRAN side.
>
> Dan Nagle a écrit :
>
>> Hello,
>>
>> Jean-Pierre Rosen wrote:
>>
>>> Nasser Abbasi a écrit :
>>>
>>>> What are the technical language specific reasons why Fortran would
>>>> be selected over Ada?
>>>>
>>> Some immediate reasons:
>>> 1) Packaging. Packages allow better organization of software, which
>>> is good for any kind of application.
>>
>>
>> Can you compare and contrast Ada packages
>> with Fortran modules and submodules?
>
> Honestly, I don't know about Fortran modules.
I think they're alot like packages. They provide a scope
where you can define variables, data types, operators,
functions, etc. They can be either PUBLIC or PRIVATE
and the USEr of the module can control which ones he
imports. They allow for a lot of name and implementation
hiding. Data types can have PRIVATE or PUBLIC internal
parts, independent of whether or not the data type itself
is PUBLIC or PRIVATE.
>
>>> 2) Strong typing. Scientific applications often deal with physical
>>> units, and Ada is great at supporting these.
>>
>>
>> What specific features of Ada provide better support
>> than the comparable feature of Fortran?
>
> Is it possible in Fortran to define three *incompatible* types Length,
> Time, and Speed, and define a "/" operator between Length and Time that
> returns Speed?
Yes, it's possible. There was a long thread inb c.l.f a
year or two ago abou this. It's a bit of a pain in the butt
to cover all the cases. Is E = m*c**2 the same as E=m*c*c?
Fortran 2003 has polymorphic variables which might make it
easier to write a complete set of units and operators. That
probably would lose some compile time checking.
>
>>> 3) User defined accuracy. Ada allows you to define the accuracy you
>>> need, the compiler chooses the appropriate representation. Note that
>>> you are not limited to only two floating point types (many machines
>>> have more than that).
>>
>>
>> How is this better than Fortran's kind mechanism?
>
> I need to be educated about Fortran's kind, but can you use it to
> specify that you want a type with guaranteed 5 digits accuracy?
Yes, Fortran allows you to specify both decimal precision
and exponent range for variables. The compiler must pick
the best representation it supports (where "best" is defined
in the standard). If it doesn't support the precision or
range, it must give an error.
>
>>> 4) Fixed points. Not available in Fortran
>>
>>
>> Agreed. How important is this for floating point work?
>> Fortran is rarely used for imbedded software (at least,
>> I wouldn't).
>
> It's not important for floating point work, it's important for fixed
> point work :-)
It's not important for Fortran work ;) .
Technically, it probably could be done under the KIND
mechanism, but I don't think any compiler support it
directly. There is enabling stuff coming in F2008.
>
> Because Fortran has no fixed points, the scientific community sees
> floating point as the only way to model real numbers. Actually, fixed
> points have nothing to do with embedded software, they are a different
> way of modelling real (in the mathematical sense) numbers, with
> different numerical properties. Depending on the problem, fixed point
> may (or not) be more appropriate.
>
>>> 5) Guaranteed accuracy, not only for basic arithmetic, but for the
>>> whole mathematical library
>>
>>
>> Can you compare Ada's accuracy requirements with Fortran's
>> support for IEEE 754?
>
> Ada's accuracy requirement is independent from any hardware (or
> software) implementation of floating points, and are applicable even for
> non IEEE machines.
Nope. The IEEE features in Fortran 2003 encourage
processors to do the right thing, but don't mandate it.
What does Ada say about things like COS(1.1E300)?
It's unclear to me what that could or should mean on a
machine with finite (or at least less than 300 ;) ) digits
of precision.
>
>>> 6) Standardization. All compilers process exactly the same language.
>>
>>
>> Again, how is this different? Fortran compilers are required
>> to be able to report use of extensions to the standard.
>
> AFAIK, there is a formal validation suite for Fortran, but
Nope, there isn't a formal validation suite for "modern"
Fortran. There was one for FORTRAN 77, but, realistically,
it wasn't very good. If you need one, I know where you can
get a real good one ;).
> 1) Compilers rarely report their validation result
> 2) A compiler is deemed "passed" if it succeeds 95% of the tests, while
> 100% is required for Ada
>
>>> 7) Interfacing. Easy to call libraries in foreing languages => all
>>> libraries available for Fortran are available for Ada.
>>
>>
>> Can you compare Interfaces.C to ISO_C_BINDING?
>> How is one better or worse than the other?
>
> Sorry, I don't know what you are refering to (except for Interfaces.C :-)
The ISO_C_BINDING module specifiecs a raft of C like
things, named constants, some procedure interfaces, etc.
There is also a BIND(C) attribute for externals that
forces the compiler to use a C compatible calling
sequence. Between that and the named constants, etc.,
you can define interfaces to just about any C function
and vice-versa. There are some purely Fortran things,
like multi-dimensional array sections, that have no
defined passing mechanism.
>
>>> 8) Concurrency, built into the language
>>
>>
>> Co-arrays and concurrent loops are coming in Fortran 2008.
>
> Concurrency has been in Ada since 1983! Moreover, it's a multi-tasking
> model, not concurrent statements model. Both models have benefits and
> drawbacks, it depends on the needs.
>
>>
>>> 9) Generics. Stop rewriting these damn sorting routines 1000 times.
>>
>>
>> Intelligent Macros are coming in Fortran 2008.
>
> I don't know what an "intelligent macro" is, but certainly generics
> (once again available since 1983"), are much more than macros, even
> intelligent ones.
>
> For one thing, the legality of generics is checked when the generic is
> compiled. This means that, provided actual parameters meet the
> requirements of the formals, there is no neeed to recheck at
> instantiation time, and ensures that any legal instantiation will work
> as expected. AFAIK, this cannot be achieved by macros.
This is a flaw (or feature?) of the macro approach. The
macro system is Fortran aware, so really stupid things
can be caught early on, but most bugs would be caught
when a version is instantiated. Basically you define a
template-like thing, which can have embedded IF-THEN logic,
and instantiate it yourself for whatever set of conditions
you need.
There's an old joke that says "all compilers are multi-pass
optimizers, some of them require the programmer to make the
first few passes." In that sense, Fortran's intelligent
macros are just like Ada's generics.
>
>>> 10) Default parameters. Makes complex subprograms (simplex...) much
>>> easier to use.
>>
>>
>> Agreed.
Agreed also. Fortran subroutines can have optional
arguments. However, there's no magic default. The
subroutine programmer must check for the absence of
an optional argument and do the right thing manually.
>>
>>> 11) Operators on any types, including arrays. Define a matrix product
>>> as "*"...
>>
>>
>> How is Ada's operators for types better or worse than Fortran's?
>> Is Ada's "*" operator better than Fortran's matmul()?
>
> More convenient to write:
> Mat1 := Mat2 * Mat3;
There's been several comments on this one. Basically,
Fortran went the route that all intrinsic operators
operate on an element-by-element basis. User defined
operators can do whatever is desired. Personally, I
think code is hard to read when * sometimes operates
one way and sometimes another. But, that's just my
opinion.
>
>>> 12) Bounds checking, with a very low penalty. Makes bounds checking
>>> really usable.
>>
>>
>> How is Ada's bounds checking better or worse than Fortran's?
>
> I may miss something on the Fortran side, but Ada's very precise typing
> allows to define variables whose bounds are delimited. If these
> variables are later used to index an array (and if the language features
> are properly used), the compiler statically knows that no out-of-bound
> can occur. In short, most of the time, an Ada compiler is able to prove
> that bounds checking is not necessary, and corresponding checks are not
> generated.
>
> In practice, compiling an Ada program with or without bounds checking
> shows very little difference in execution speed, because only the really
> useful checks are left, all the spurious ones have been eliminated.
>
Ada's is surely better. Knowing that a subscript has to be
in range, because it's checked when a value is assigned to
the subscript variable, has to be more efficient than what
Fortran can do. In general, Fortran has to check the value
of the subscripts on every array reference. In practice,
most array references take place in DO loops and compilers
can usually hoist the checks outside the loop, so they have
minimal cost at run time.
Dick Hendrickson
Brooks Moses
> Gareth Owen wrote:
>>I think assuming anything about A*B is extremely dangerous. Just of
>>the top of my head, Ada and Matlab think it means matrix
>>multiplication and Fortran and Mathematica think its pointwise
>>multiplication.
>>
>>It means basically nothing in C, and in C++ it means whatever the
>>matrix class implementor wanted it to mean.
>
> My stance on A*B is this: if A*B denotes matrix multiplication, then A/B should
> denote matrix 'division': B^-1*A. Which means you need to standardize matrix
> inversion/linear-equations solution into the language. Which is batshit crazy.
I believe that's how Matlab does it.
Then again, for Matlab's purposes, standardizing matrix inversion and
linear-equation solution into the language is entirely reasonable.
Marc A. Criley
> Ken Plotkin a écrit :
>> Its structured nature and verbosity were intended to improve
>> readibility, maintenance and reliability.
>
> Yep, Ada mains goals.
As an interesting aside, a software analysis tool that's been around for
a few years, "Understand for Ada" (there's also versions for Fortran and
other languages, see www.scitools.com) recently added the capability to
generate "Control Flow Diagrams" (CFDs) from source code. Essentially
these are flow charts, where the contents of the boxes are the source
code statements directly lifted from the code.
To an experienced programmer this isn't a big deal, but it's a big help
for those who do little or no programming to help them understand and
follow what's going on in a given subprogram.
The Ada programming penchant for more expressive (or verbose :-) naming
is of real benefit here, because what happens in each statement or
conditional is usually more descriptive than it tends to be in other
languages.
-- Marc A. Criley
-- McKae Technologies
-- www.mckae.com
-- DTraq - XPath In Ada - XML EZ Out
Georg Bauhaus
> What does Ada say about things like COS(1.1E300)?
> It's unclear to me what that could or should mean on a
> machine with finite (or at least less than 300 ;) ) digits
> of precision.
It means the compiler will tell you ;-)
Messages will indeed depend on the amount of digits possible,
but compilers cannot give up just because of a slightly bigger
number.
4. if 1.1E300 < 1.2E300 then
|
>>> warning: condition is always True
This can be compiled, and can be used in conditionals etc. without
trouble.
The generic Ada.Numerics.Generic_Elementary_Functions
can be instantiated with any floating point type, so if you get
a type definition of at least 300 digits past the compiler, then
COS(1.1E300) might well have its standard meaning ;-)
-- Georg
Aldebaran
> I like to discuss the technical reasons why Ada is not used as much as
> Fortran for scientific and number crunching type applications?
>
>
And what about Ocaml?
Aldebaran
from Taurus
glen herrmannsfeldt
> Nasser Abbasi wrote:
>>I personally think that one way to make Ada popular for scientific use is to
>>publish a version of the Numerical recipes book in Ada.
(snip)
> You cannot do this unless you get the authors of Numerical Recipes on
> board, which would probably be difficult. I think a literal translation
> of their Fortran or C code to Ada could not be posted online without
> their permission.
The rules are complicated and country dependent.
On thing, though, you most likely don't want a literal translation, as
that likely negates any advantage that Ada might have.
If it is not a literal translation then it is likely a different
expression of the ideas, and so not infringing on the copyright.
You probably can't call it "Numerical Recipes" if that is trademarked,
but that is a different question. (You should probably reference NR,
though.)
As usual, IANAL, but most likely the code could be posted. One would
then need to buy the book to get the text to go along with the code, and
thus increasing sales of the book.
-- glen
Dmitry A. Kazakov
> Jean-Pierre Rosen wrote:
>> Is it possible in Fortran to define three *incompatible* types Length,
>> Time, and Speed, and define a "/" operator between Length and Time that
>> returns Speed?
> Yes, it's possible. There was a long thread inb c.l.f a
> year or two ago abou this. It's a bit of a pain in the butt
> to cover all the cases. Is E = m*c**2 the same as E=m*c*c?
Hmm, where is any problem? As I remember 2 is integer in Fortran. I hope it
can distinguish signatures ** : R x I -> R and ** : R x R -> R. Or do you
mean a geometrical explosion of variants?
> Fortran 2003 has polymorphic variables which might make it
> easier to write a complete set of units and operators. That
> probably would lose some compile time checking.
That depends on which kind of polymorphism it is. Ada provides three forms
of:
1. generics (like C++ templates) and overloading
2. tagged types (like C++ classes)
3. discriminated types.
All three can be used for dimensioned values.
The last one is IMO the most promising, because it supports constrained
subtypes. It is similar to Positive being a constrained Integer. So, for
example, Energy can be statically constrained Dimensioned. Now, when all
constraints are statically known, the compiler can potentially remove all
run-time checks, as well as any memory overhead required to keep the
dimension at run-time.
Then there is a problem of constraint propagation. Developing a matrix
library you surely would like to have dimensioned vectors and matrices all
constrained in a "coherent" way rather than on per-element basis. I doubt
that either 1. or 2. would be able to do it in an easy way.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
Rich Townsend
Exactly. But I don't think you would find a single person in this newsgroup who
would support inclusion of a solver in Fortran. And the reason would be netlib.
In this respect, Matlab is a language *AND* a library; whereas Fortran is just a
language, and netlib is the numerics metalibrary for it.
cheers,
Rich
Brooks Moses
> On Tue, 23 May 2006 17:09:03 GMT, Dick Hendrickson wrote:
>>Fortran 2003 has polymorphic variables which might make it
>>easier to write a complete set of units and operators. That
>>probably would lose some compile time checking.
>
> That depends on which kind of polymorphism it is. Ada provides three forms
> of:
>
> 1. generics (like C++ templates) and overloading
> 2. tagged types (like C++ classes)
> 3. discriminated types.
> Then there is a problem of constraint propagation. Developing a matrix
> library you surely would like to have dimensioned vectors and matrices all
> constrained in a "coherent" way rather than on per-element basis. I doubt
> that either 1. or 2. would be able to do it in an easy way.
For what it's worth, the OpenFOAM CFD program that I've been working
with (written in C++) has dimensioned variables, with dimension
checking. It's all run-time, though; they've only got one type of
"dimensioned variable" (a class with the variable value and a
length-seven array containing the exponents of the dimensions) and then
assignments and arithmetic operators check to make sure the dimensions
agree.
What they've done for their array library is to define a dimensioned
array by adding dimension information to an array of undimensioned
scalars, rather than constructing it directly as an array of dimensioned
individual numbers.
In practice, it seems to work quite well, and I suspect the run-time
checking is generally of negligible cost since it's happening only once
per array operation. (Of course, in code where it does happen once per
scalar operation, it's rather more expensive.)
Gautier
> I personally think that one way to make Ada popular for scientific use is to
> publish a version of the Numerical recipes book in Ada.
>
> I have been waiting for this for long time.
It won't happen spontaneously...
The best way is to help this happening.
Good news are that, you can translate the whole Pascal version through a recent version
of P2Ada (it works!); there is some manual rework to make it compile and more to take
advantage of Ada constructs like unconstrained arrays (instead of arrays with fixed
dimension in Pascal!), standardized floating-points, I/O or modularity, but it is
definitely doable.
More, here: http://www.mysunrise.ch/users/gdm/gsoft.htm#p2ada
Good luck!
Gautier
__
Rich Townsend
> Nasser Abbasi:
>
>> I personally think that one way to make Ada popular for scientific use
>> is to publish a version of the Numerical recipes book in Ada.
>>
>> I have been waiting for this for long time.
>
>
> It won't happen spontaneously...
> The best way is to help this happening.
> Good news are that, you can translate the whole Pascal version through a
> recent version of P2Ada (it works!); there is some manual rework to make
> it compile and more to take advantage of Ada constructs like
> unconstrained arrays (instead of arrays with fixed dimension in
> Pascal!), standardized floating-points, I/O or modularity, but it is
> definitely doable.
>
I head they did the C version with f2c. Hehehe.
cheers,
Rich
Dick Hendrickson
Dmitry A. Kazakov wrote:
> On Tue, 23 May 2006 17:09:03 GMT, Dick Hendrickson wrote:
>
>
>>Jean-Pierre Rosen wrote:
>
>
>>>Is it possible in Fortran to define three *incompatible* types Length,
>>>Time, and Speed, and define a "/" operator between Length and Time that
>>>returns Speed?
>>
>>Yes, it's possible. There was a long thread inb c.l.f a
>>year or two ago abou this. It's a bit of a pain in the butt
>>to cover all the cases. Is E = m*c**2 the same as E=m*c*c?
>
>
> Hmm, where is any problem? As I remember 2 is integer in Fortran. I hope it
> can distinguish signatures ** : R x I -> R and ** : R x R -> R. Or do you
> mean a geometrical explosion of variants?
>
>
I was thinking of the geometric explosion. You'd need
routines to do (mass) times (velocity squared),
(velocity) times (velocity), (mass) times (velocity),
and (mass*velocity) * velocity. And intermediate types to
hold the partial answers. You probably don't want to say
E = momentum*velocity. But that's what you'd get if
you write it as m*c*c. Straightforward to cover all
of this, but just a ton of cases..
Dick Hendrickson
Martin Dowie
Hmmm, that sounds suspiciously like what has just been standardized
within Ada (Ada2005 that is).
Here is a link to the "Rationale" written by John Barnes:
http://www.adaic.org/standards/05rat/html/Rat-7-6.html
Cheers
-- Martin
Dr Ivan D. Reid
Wasn't that a song by Neil Sedaka?
--
Ivan Reid, Electronic & Computer Engineering, ___ CMS Collaboration,
Brunel University. Ivan.Reid@[brunel.ac.uk|cern.ch] Room 40-1-B12, CERN
KotPT -- "for stupidity above and beyond the call of duty".
Dr. Adrian Wrigley
> Hello,
>
> Dr. Adrian Wrigley wrote:
>
> <snip>
>
>> Isn't this a bit more like MPI?
>
> Well, it's like MPI minus the rubbish.
>
>> In Ada, these concurrency features are very robust and streamlined.
>> This is because tasking was a primary goal of the language design.
>>
>> For a typical Fortran application like weather forecasting, this
> ^^^^
>> is exactly the architecture you might choose. It may be
>> hardcore numerical code.
>
> I'm not sure which antecedent "this" references,
> but the meteorological folks are one of the main
> forces behind co-arrays.
In a weather forecasting program you want to have data
acquisition (real-time), prediction (computation) and display
(real-time GUIs) running on a continuous, high uptime basis
across a network of machines.
If Fortran had strong multitasking, real-time and distributed
capabilities, these goals would be reasonable and achievable
within the language. Absence of these features means such
systems would often (I guess) be multi-language setups, with things
like Java, C++, Tcl/Tk, shell scripts, cron jobs etc. playing a part.
Has anyone here worked on a big meteorological system? Am I right?
Co-arrays fill a longstanding, unmet need in programming languages.
Fortran, in particular, should have had this feature long ago.
But the design/semantics are challenging to get something which
is truly general-purpose, useful and understandable.
Co-arrays would be great if they were widely available and performant.
But they're not :(
Designing a co-array system involves bridging the semantic gap
between the software author, the compiler and the hardware
architecture. The Co-array Fortran proposals seem to fill an
existing need within the community, but I don't think make a
good model to adopt in other languages. I did briefly work
on more general ideas for language/hardware co-design using
co-arrays and similar. Initial results were encouraging, but
to make use of the technology, you really need a custom parallel
processor built. And rewriting your software :(
--
Adrian
Jeffrey Creem
The problem is that GSL is GPL which is fine if your intent is to "Make
free software" popular but at times this is in conflict with making "Ada
Popular" in some application. They are probably both worthy goals,
but pretty much everything I do for Open Source Ada I use GPL +
linking/generics exception (GMGPL). Any direct translation of the GSL is
likely to result in the Ada version being pure GPL and thus limit its
usefulness in some areas.
Dan Nagle
Dr. Adrian Wrigley wrote:
<snip>
> If Fortran had strong multitasking, real-time and distributed
> capabilities, these goals would be reasonable and achievable
> within the language. Absence of these features means such
> systems would often (I guess) be multi-language setups, with things
> like Java, C++, Tcl/Tk, shell scripts, cron jobs etc. playing a part.
> Has anyone here worked on a big meteorological system? Am I right?
I don't know, perhaps someone at a meteorological center
can answer. There are several Fortran interfaces to pthreads,
and there's always OpenMP.
> Co-arrays fill a longstanding, unmet need in programming languages.
> Fortran, in particular, should have had this feature long ago.
> But the design/semantics are challenging to get something which
> is truly general-purpose, useful and understandable.
> Co-arrays would be great if they were widely available and performant.
> But they're not :(
Actually, they're a proven design from Cray. At the last meeting
of the Fortran committee (May 06), my impression from the vendors
present was that customers are demanding co-arrays so strongly
that they will be implemented rather quickly, now that the design
has stabilized.
> Designing a co-array system involves bridging the semantic gap
> between the software author, the compiler and the hardware
> architecture. The Co-array Fortran proposals seem to fill an
> existing need within the community, but I don't think make a
> good model to adopt in other languages.
See UPC (a/k/a "Unified Parallel C" IIRC) for a similar C feature.
> I did briefly work
> on more general ideas for language/hardware co-design using
> co-arrays and similar. Initial results were encouraging, but
> to make use of the technology, you really need a custom parallel
> processor built. And rewriting your software :(
But today, interprocessor communications are approaching
the performance of memory buses. I believe co-arrays
will deliver performance at or better than MPI on many architectures,
and in many clusters.
Any application re-write is minimal compared to inserting MPI calls.
John
Nasser Abbasi wrote:
> I like to discuss the technical reasons why Ada is not used as much as
> Fortran for scientific and number crunching type applications?
>
I have some historical observations to add to the discussion. I can
tell about how Ada was discussed as a candidate for number crunching in
one very large application domain.
Quite a few (20?) years ago there was a conference in Albuquerque to
describe Ada's potential in the Department of Energy national labs.
Then as now the labs use large number crunching computers to compute
complex physics models.
There were a couple of mostly unbiased papers circulated and discussed
that compared languages. I presented some numerical modelling work in
Ada that I was doing at LLNL. As I recall Ada was praised on technical
and management criteria and scarcely a discouraging word was heard.
But I think that might have been the high water mark of Ada's
visibility to that community, where intensely numeric computation
takes place.
My sense is that the outcome (that Fortran is the principle language
for scientific modelling) comes from sound engineering judgement. "If
it ain't broke, don't replace it." If there are gains that Ada might
bring (and I believe there probably are), the difficulty and
uncertainty of a changeover overwhelm the benefits.
Ada did continue to make substantial contributions to several LLNL
programs, however not in the numerical computation domain.
John Woodruff
retired software engineer
Dr. Adrian Wrigley
>
> Dr. Adrian Wrigley wrote:
...
>> I did briefly work
>> on more general ideas for language/hardware co-design using
>> co-arrays and similar. Initial results were encouraging, but
>> to make use of the technology, you really need a custom parallel
>> processor built. And rewriting your software :(
>
> But today, interprocessor communications are approaching
> the performance of memory buses. I believe co-arrays
> will deliver performance at or better than MPI on many architectures,
> and in many clusters.
>
> Any application re-write is minimal compared to inserting MPI calls.
Thank you for your input on this topic. I had looked at things
like UPC when I was looking into the topic. There still seems
to be quite a spread of different ideas, but only modest "progress".
Something like the new 'Cell' processor would be a good target
for a co-array language. But instead, the Cell programming tools
have a disappointing, ad-hoc collection of programming (band) aids
to help coders use the parallelism. It's expected to be "guru" level
coding to get decent efficiency code at the metal.
As regards interprocessor communications vs. memory buses, it depends
at what levels you make the comparisons. On chip memory arrays
may be 1000's of bits wide at GHz speeds. Communications between
processor chips are a small fraction of that.
The challenge for co-array and SIMD computing is to work out
simple hardware that can utilize inter- and intra-chip
communications and memories efficiently. This needs to have
a sensible programming model (eg assembly language, instruction
set architecture). Only then is it worth considering what language
features (if any) are necessary to compile for it.
Sadly, what passed for SIMD computing in the '70s and '80s
was way too restrictive and often inefficient for its capabilities
to be worth providing for in general-purpose languages.
Progress is glacial :(
I wish the Fortran committee the best of luck with their co-arrays!
--
Adrian
Dan Nagle
Dr. Adrian Wrigley wrote:
<snip>
> As regards interprocessor communications vs. memory buses, it depends
> at what levels you make the comparisons. On chip memory arrays
> may be 1000's of bits wide at GHz speeds. Communications between
> processor chips are a small fraction of that.
Yes. The mix of what's to be on-chip is always changing.
Some folks (with applications programmer perspectives) were
a little unsure co-arrays are a long-term solution (remember
what happened to HPF). I expect co-arrays to work well
on any architecture from SMP to DMP, at least as well
as the competing spellings of parallelism.
> The challenge for co-array and SIMD computing is to work out
> simple hardware that can utilize inter- and intra-chip
> communications and memories efficiently. This needs to have
> a sensible programming model (eg assembly language, instruction
> set architecture). Only then is it worth considering what language
> features (if any) are necessary to compile for it.
> Sadly, what passed for SIMD computing in the '70s and '80s
> was way too restrictive and often inefficient for its capabilities
> to be worth providing for in general-purpose languages.
We usually call co-arrays SPMD (single program multiple data)
because it's not really "single instruction", but check
the synchronization rules.
> Progress is glacial :(
Yes. :-(
> I wish the Fortran committee the best of luck with their co-arrays!
Thanks. Best of luck with Ada.
Nasser Abbasi
"Martin Dowie" <martin...@btopenworld.com> wrote in message
news:Z5-dnZJnkvd...@bt.com...
WOW! thanks for the link. I had no idea Ada now supports all these useful
Matrix operations in its libraries. There should be more such functions, but
this is a great start. I have gnat2005, so I'll see if I get a change to try
the solve function and compare it to Matlab's (ofcourse Matlab has much much
more Matrix related functions, but for Ada, this is a great start in the
right direction).
Nasser
GF Thomas
"Dan Nagle" <dann...@verizon.net> wrote in message
news:U4Ocg.7543$ix2.6912@trnddc03...
> Best of luck with Ada.
>
Ada doesn't depend on luck in the way that FORTRAN does.
--
You're Welcome,
Gerry T.
______
"There's man all over for you, blaming on his boots the fault of his
feet." -- Samuel Beckett.
robin
> Jean-Pierre Rosen wrote:
> > In practice, compiling an Ada program with or without bounds checking
> > shows very little difference in execution speed, because only the really
> > useful checks are left, all the spurious ones have been eliminated.
>
> In practice, bounds checking is available with every Fortran compiler.
But it's not part of the language.
robin
news:epcs4e...@hunter.axlog.fr...
> Nasser Abbasi a écrit :
> > What are the technical language specific reasons why Fortran would be
> > selected over Ada?
> >
> Some immediate reasons:
> 1) Packaging. Packages allow better organization of software, which is
> good for any kind of application.
Modules?
> 9) Generics. Stop rewriting these damn sorting routines 1000 times.
Generic procedures are available in Fortran.
> 10) Default parameters. Makes complex subprograms (simplex...) much
> easier to use.
>
> 11) Operators on any types, including arrays. Define a matrix product as
> "*"...
Well, you can do that too in Fortran with UDO's (for another symbol).
But there's no need to, with MATMUL (a builtin matrix
multiplication procedure).
robin
"Nasser Abbasi" <n...@12000.org> wrote in message
news:sxlcg.75860$F_3....@newssvr29.news.prodigy.net...> news:tHkcg.6937$kR6.484@trnddc05...
>
> >> 11) Operators on any types, including arrays. Define a matrix product as
> >> "*"...
> >
> > Is Ada's "*" operator better than Fortran's matmul()?
>
>
> It is clear that
>
> A*B
>
> is easier to read and understand than
>
> MATMUL(A,B)
>
> would you not agree?
But a casual user would ask, does A*B mean term by term or matrix product?
If one, then how is the other distinguished?
A casual user would probably recognize MATMUL as
being matrix multiplication, not term by term.
GF Thomas
"robin" <rob...@bigpond.com> wrote in message
news:h8Scg.9804$S7....@news-server.bigpond.net.au...
[...]
> > It is clear that
> >
> > A*B
> >
> > is easier to read and understand than
> >
> > MATMUL(A,B)
> >
> > would you not agree?
>
> But a casual user would ask, does A*B mean term by term or matrix
product?
> If one, then how is the other distinguished?
> A casual user would probably recognize MATMUL as
> being matrix multiplication, not term by term.
>
Quite.
Recently on the comp-FORTRAN newslist we had such disinformation from a
self-styled nasa bigbrain who claimed that epx(A) =exp(Int(0,t)A(s)ds). The
same bargain bigbrain lately poo-poohed C/C++'s inability to host a stiff
ODE solver when such C/C++ codes have been available within .gov for some
time now, without f2c, and gratis to .gov employees . Little wonder that
Fortran is priced as a Challenger + crew/decade. What gives?
--
Boom,
Gerry T.
Jan Vorbrüggen
> Time, and Speed, and define a "/" operator between Length and Time that
> returns Speed?
Yes.
> I need to be educated about Fortran's kind, but can you use it to
> specify that you want a type with guaranteed 5 digits accuracy?
Yes.
> Because Fortran has no fixed points, the scientific community sees
> floating point as the only way to model real numbers.
Ah nonsense. You often need the range, and the constant relative precision
of FP is what is often - but not always, of course - needed in physical
simuilation.
> Ada's accuracy requirement is independent from any hardware (or
> software) implementation of floating points, and are applicable even for
> non IEEE machines.
The same is true for Fortran.
> More convenient to write:
> Mat1 := Mat2 * Mat3;
While that is true, it is much less convenient to read - see the seperate
thread on the issue.
>> How is Ada's bounds checking better or worse than Fortran's?
>
> I may miss something on the Fortran side, but Ada's very precise typing
> allows to define variables whose bounds are delimited. If these
> variables are later used to index an array (and if the language features
> are properly used), the compiler statically knows that no out-of-bound
> can occur. In short, most of the time, an Ada compiler is able to prove
> that bounds checking is not necessary, and corresponding checks are not
> generated.
It's a little bit more difficult for a Fortran compiler, but an equivalent
program - one that, directly or indirectly refers to the array bounds in
the loop parameters - should be optmizable in the same way. With array
expressions, Fortran has an additional and idiomatic way of doing this.
Jan
Dmitry A. Kazakov
> Dmitry A. Kazakov wrote:
>> On Tue, 23 May 2006 17:09:03 GMT, Dick Hendrickson wrote:
>>>Fortran 2003 has polymorphic variables which might make it
>>>easier to write a complete set of units and operators. That
>>>probably would lose some compile time checking.
>>
>> That depends on which kind of polymorphism it is. Ada provides three forms
>> of:
>>
>> 1. generics (like C++ templates) and overloading
>> 2. tagged types (like C++ classes)
>> 3. discriminated types.
> [...]
>> Then there is a problem of constraint propagation. Developing a matrix
>> library you surely would like to have dimensioned vectors and matrices all
>> constrained in a "coherent" way rather than on per-element basis. I doubt
>> that either 1. or 2. would be able to do it in an easy way.
>
> For what it's worth, the OpenFOAM CFD program that I've been working
> with (written in C++) has dimensioned variables, with dimension
> checking. It's all run-time, though; they've only got one type of
> "dimensioned variable" (a class with the variable value and a
> length-seven array containing the exponents of the dimensions) and then
> assignments and arithmetic operators check to make sure the dimensions
> agree.
Yes, this is also the variant 3, but without an ability to have subtypes,
because the discriminant is not exposed. I implemented a commercial C++
library (used for data acquisition an control) in a similar way. The
problem is that one can change both value and dimension of a variable,
which is a safety breach.
GPL Ada version, I wrote allows things like:
subtype Speed is Measure (Velocity);
Car_Speed : Speed; -- Only velocities are allowed
. . .
Car_Speed := 10.0 * km / h; -- OK
Car_Speed := A; -- Ampere is illegal, Constraint_Error
> What they've done for their array library is to define a dimensioned
> array by adding dimension information to an array of undimensioned
> scalars, rather than constructing it directly as an array of dimensioned
> individual numbers.
Yes, so did I for similar things (dimensioned fuzzy numbers, linguistic
variables etc.)
> In practice, it seems to work quite well, and I suspect the run-time
> checking is generally of negligible cost since it's happening only once
> per array operation. (Of course, in code where it does happen once per
> scalar operation, it's rather more expensive.)
Overhead exists, and it is relatively high when you do something like:
forall Matrix do some per-element operation involving dimensions. To get
rid of this overhead one should manually fold dimension checks in all
cross-typed operations: like [Dimensioned] Matrix x [Dimensioned] Scalar,
[Dimensioned] Matrix x [Dimensioned] Vector. If there are many types, many
operations and many arguments, this quickly brings the problem of
geometrical explosion back.
Basically, this all is a consequence of lacking a constraint propagation
mechanism capable to move dimension checks out of bodies. Theoretically the
compiler could do it when all operations were inlined, but practically, I
saw no compiler that does it. Then one cannot inline everything. I think
the language should provide something for this, in particular, separation
of a subroutine body into inlined (dimension checks) and not inlined
(numeric semantics) parts.
Jean-Pierre Rosen
> What does Ada say about things like COS(1.1E300)?
> It's unclear to me what that could or should mean on a
> machine with finite (or at least less than 300 ;) ) digits
> of precision.
annex G of the Ada reference manual, and for this precise issue, G.2.4(10).
The idea is that there is a maximum angle threshold, beyond which
accuracy cannot be guaranteed. But this is defined and documented. Ada
is not in the business on making requirements that would be impossible
to meet. Ada is about having actual implementations that work, in the
most *possibly* portable way.
--
---------------------------------------------------------
J-P. Rosen (ro...@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr
Jan Vorbrüggen
>>the real and imaginary part in memory as he sees fit,
> Although Fortran does restrict the implementation, so the langauge
> implementer is not fully free.
Is that through sequence association - i.e., I can assume (conceptually)
an EUIVALENCE of two reals, the real and imaginary part in that order, to
be in place for a complex variable?
Jan
J.F. Cornwall
In my US Air Force days, I worked at a large global weather-forecasting
facility. We had multiple data input systems (a variety of comm links
talking to several Univac mainframes), multiple number-crunching systems
(a couple more Univacs and a Cray), and an cluster of 40 or so Vax
11/780s for interactive tweaking of the forecasts. The majority of the
software for the comm was in assembler, just about all of the remainder
was Fortran (IV and 77, this was back in the early 80's...).
We also used Fortran mixed with assembly code for a new comm front-end
machine that was implemented in '88. Fortran was used for comm, utility
programs, forecasting models, database input/output/maintenance, and
just about everything else in that system. Worked fine.
Nowadays, I have no idea what they're running. Bet there's still a lot
of Fortran though :-)
Jim
Dr. Adrian Wrigley
Interesting.
I *think* you are supporting my view that in practice, Fortran
requires additional support or coding outside of the language to tie
together the different parts of a complex system.
You speak of utility programs, forecasting programs, database I/O
programs. Invoking these in the right order, at the right time,
on the right files at the right terminals is always done
outside of the pure Fortran application. At the very least
it requires an OS command interpreter. It probably involves
scripts to delete old files or do other housekeeping.
In Ada, the separate program components can form a *single*
running application program entity, with a single invocation - even
if the program is running across several loosely connected machines
and consists of many different executable files. The program
execution is a network of cooperating processes and shared
data stores. Parts of the program can even be recompiled as
it runs - without affecting the shared data stores or other
executing tasks. In fact Ada supports persistent variables
with hold their values even if the program is stopped completely
and restarted later. No mainstream language comes even close
to this program execution model.
--
Adrian
robin
news:PkHcg.90575$Fs1....@bgtnsc05-news.ops.worldnet.att.net...
>
> Ada's is surely better. Knowing that a subscript has to be
> in range, because it's checked when a value is assigned to
> the subscript variable, has to be more efficient than what
> Fortran can do. In general, Fortran has to check the value
> of the subscripts on every array reference.
It can do this only if it is a compiler option.
It is not a feature the language.
> In practice,
> most array references take place in DO loops and compilers
> can usually hoist the checks outside the loop, so they have
> minimal cost at run time.
Dick Hendrickson
robin wrote:
> "Dick Hendrickson" <dick.hen...@att.net> wrote in message
> news:PkHcg.90575$Fs1....@bgtnsc05-news.ops.worldnet.att.net...
>
>>Ada's is surely better. Knowing that a subscript has to be
>>in range, because it's checked when a value is assigned to
>>the subscript variable, has to be more efficient than what
>>Fortran can do. In general, Fortran has to check the value
>>of the subscripts on every array reference.
>
>
> It can do this only if it is a compiler option.
> It is not a feature the language.
There's a ambiguous "it" in those sentences. ;)
But, if "it" refers to Fortran, subscript bounds rules
ARE a feature of the language. You are NEVER allowed to
execute an out-of-bounds array reference in a Fortran
program. In practice, the historical run-time cost of
checking bounds was [thought to be] too high, so compilers
either didn't do it, or did it under some sort of command
line option control.
Dick Hendrickson
Richard E Maine
Yes. And it is a bit more than conceptually. The standard is pretty
explicit about it.... well at least the f77 standard is. I'm failing to
find quite the same words in the f2003 standard. I have no real doubt
what the answer to an interp request on it would be (based on
compatibility with f77), but I'm not finding the explicit words in
f2003. Can anyone pint out where I might have missed them?
In f2003 we have, in the section on complex type (4.4.3)
"The values of a complex type are ordered pairs of real values. The
first real value is called the real part. The second real value is
called the imaginary part."
But these words talk about values - not about representations. This
sounds to me like a description of a mathematical concept. I find words
elsewhere saying that complex occupies two consecutive numeric storage
units, which says something about representation, but I can't find the
words to say what those two storagte units have to look like.
In contrast, f77 says, in its section on complex type (4.6)
"The representation of a complex datum is in the form of an ordered
pair of real data. The first of the pair represents the real part
of the complex datum and the second represents the imaginary part.
Each part has the same degreee of approximation as for a real datum.
A complex datum has two consecutive numeric storage units in a
storage sequence: the first storage unit is the real part and the
second storage unit is the imaginary part."
While the wods about an ordered pair look pretty similar, the f77
version has the word "representation", while the f2003 version doesn't.
That makes them say different things acccording to me, although I'm sure
the difference is unintentional. The f77 version seems to me to say the
same thing twice, but the f2003 version dropped it down to zero times.
Section 17.1 of f77 says the same thing a third time, but f2003 doesn't
seem to have that copy either.
This change in wording happened between f77 and f90.
I see that even the f77 version doesn't quite seem to say what I'm sure
was intended. Again, I might have missed it, but...
F77 talks about the storage units being the real and imaginary parts,
and it says that each part has "the same degree of approximation" as for
a real datum. But I don't see that it says it has the same
representation as a real datum. Now by the time you are tied down that
much, I can't see why the representation wouldn't be the same in
practice, but I don't say that this says it actually has to be. I'm sure
that is the intent, particularly given the words in 17.2(11) and (12).
Those words in section 17 don't say what values the partially associated
entities become defined with, but there are no other plausible candidate
values and it would be quite unlike the usual practice of the standard
to say that they become defined, but to omit any mention of what value
they become defined with. Sometimes things get processor-dependent
values, but the standard at least tends to say that such values are
processor dependent rather than just saying that there is a value, but
being silent about what it might be.
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
Dick Hendrickson
Jan Vorbrüggen wrote:
Yes. COMMON, EQUIVALENCE, and use as an argument usually
require a fixed structure for complex variables.
However, essentially all of Fortran's rules have an "as if"
clause somewhere in them. If the compiler is sufficiently
clever (and can see enough of the whole program) it can do
anything with complex variables. Keeping temporaries in
registers and discarding them when they become dead is
common practice and is standard conforming.
Dick Hendrickson
>
> Jan
Dr. Adrian Wrigley
>
>
> robin wrote:
>> "Dick Hendrickson" <dick.hen...@att.net> wrote in message
>> news:PkHcg.90575$Fs1....@bgtnsc05-news.ops.worldnet.att.net...
>>
>>>Ada's is surely better. Knowing that a subscript has to be
>>>in range, because it's checked when a value is assigned to
>>>the subscript variable, has to be more efficient than what
>>>Fortran can do. In general, Fortran has to check the value
>>>of the subscripts on every array reference.
>>
>>
>> It can do this only if it is a compiler option.
>> It is not a feature the language.
>
> There's a ambiguous "it" in those sentences. ;)
>
> But, if "it" refers to Fortran, subscript bounds rules
> ARE a feature of the language. You are NEVER allowed to
> execute an out-of-bounds array reference in a Fortran
> program.
...
So what does the standard say must happen if you attempt
such an access? Can a program fail unpredictably under
such (rather common!) circumstances - as routinely happens
in C and C++, sometimes at great cost?
--
Adrian
Richard E Maine
> There's a ambiguous "it" in those sentences. ;)
Ah, Dick. You missed such a great opportunity to phrase that
self-referentially as just "It is ambiguous." :-)
J.F. Cornwall
Actually, in that particular environment, everything was tied together
in a complicated web of cross-ties. The Fortran code couldn't do
everything, the assembly code couldn't do everything, the scripting and
batch control languages couldn't do everything. etc... That would have
been the case had we been using Ada, as well.
And we did look at Ada when starting out on the comm front-end project.
At that time it wouldn't do what we needed it to do, so we went with a
continuing mixture of F77 and assembler. Sorry, I don't recall the
details of what we needed that it couldn't do, recall that this was in
the early 1980s.
Jim
Dick Hendrickson
The Fortran standard says nothing at all about what must
happen for most run-time errors. There is a requirement
that a compiler be able to diagnose syntax-like errors at
compile time. There is also a requirement that some
(unspecified) I/O errors and some memory management errors
be checked for at run time. The job will abort unless the
program uses one of the error detection methods. But for
things like subscript bounds errors, or subroutine argument
mismatches, the standard doesn't impose anything on the
compiler.
In general, the standard imposes restrictions on standard
conforming programs, not on the compiler. This allows
compilers to extend the standard in "useful" ways.
Technically, a standard conforming program is not allowed
to use these extensions, but many do ;). Most compilers
implement a command line option to do enhanced syntax
checking and report use of extensions.
Subscript bounds errors usually go unchecked and do
whatever they do. They're really fun to debug because
adding a PRINT statement usually moves the effect to
some other part of the program. This isn't Fortran's
greatest strength ;) . It was a compromise between
safety and speed.
The other big problem with [old] Fortran programs was
messing up the argument list in a procedure call.
Separate compilation made this a lot easier to do.
The Fortran 90 addition of MODULES essenially closes
this hole. Most procedure interfaces now can be explicit
and the compiler must check for calling consistency.
It's harder to shoot yourself in the foot now, but
people can still lie to the compiler.
Dick Hendrickson
> --
> Adrian
>
Richard E Maine
> The Fortran 90 addition of MODULES essenially closes
> this hole. Most procedure interfaces now can be explicit
> and the compiler must check for calling consistency.
Unless I missed it, I don't think that the standard actually requires
compilers to check for calling consistency. I don't think it is a
constraint or any of those other things that the standard requires
diagnosis of.
The standard is "clearly" designed to encourage such diagnosis and to
make it "natural" for compilers to do so. To my knowledge, every
compiler in existence does so. So perhaps the point is a bit academic,
I'll admit. But I'll make it anyway.
Of course, if we are being as nitpicky as I am above, you can probably
your statement by noting that you said "must" instead of "shall". :-)
Dr. Adrian Wrigley
...
> The other big problem with [old] Fortran programs was
> messing up the argument list in a procedure call.
> Separate compilation made this a lot easier to do.
> The Fortran 90 addition of MODULES essenially closes
> this hole. Most procedure interfaces now can be explicit
> and the compiler must check for calling consistency.
> It's harder to shoot yourself in the foot now, but
> people can still lie to the compiler.
I think this is an area that Ada really shines. The standard
requires numerous checks for consistency at both compile
time and runtime. Versions of code that don't match properly
can't be linked together or can't be run together (as appropriate).
Using the language gives a feeling of integrity of coding,
with mistakes often being caught very early on.
Unfortunately, the language features for integrity cannot
be added to an existing language without breaking old
code. This is because the integrity features are often a result
of prohibiting "dodgy" code, flawed syntax or misfeatures.
The history of the C family of languages illustrates this.
I'm not sure where modern Fortran sits in relation to
its forbears in terms of safety and security though.
It's noteworthy that Ada and Fortran are on convergent
paths (modules, user defined types, templates etc).
With array subscripts, an exception must be raised if the
bounds are exceeded. The same with arithmetic operations.
(curiously, compiling Ada under gcc (GNAT), a compilation
switch is needed to be standards compliant - a mistake:().
The checks can be switched on and off in the source code
as desired.
One of the benefits of the compile- and run-time checking
is that refactoring code becomes much easier because the
compiler will usually tell you about what parts haven't
been fixed up yet. Languages like C or Perl are at the
opposite end of the spectrum, I find. From what I read here,
Fortran is somewhere in between.
--
Adrian
Dr. Adrian Wrigley
> Dr. Adrian Wrigley wrote:
>> On Wed, 24 May 2006 12:56:29 +0000, J.F. Cornwall wrote:
>>
>>> Dr. Adrian Wrigley wrote:
>>>> On Tue, 23 May 2006 17:07:06 +0000, Dan Nagle wrote:
...
You're quite right.
But one thing apparent in this discussion is that the Ada programmer's
view of Fortran is the FORTRAN 77 many learned in college, but
the Fortran programmer's view of Ada is of Ada 83, when that was
hot technology. Neither view has much relevance in determining
the technical suitability of the contemporary languages for
new projects.
I'd be overselling the features of modern Ada to say that the
scripting and batch control 'glue' can *all* be done within the
language - but a huge part of it can be. And this brings a major
benefit to system portability, complexity and integrity.
--
Adrian
Richard E Maine
> It's noteworthy that Ada and Fortran are on convergent
> paths (modules, user defined types, templates etc).
Yes.
On multiple occasions, I have often heard Fortran 77 users misleadingly
describe Fortran 90 and subsequent versions as like a cross between
Fortran 77 and C. I attribute this description mostly to low breadth of
language exposure from people who have not seen much other than those
two languages and thus narrowly associate features like structures with
C.
When I hear this misleading description, the one-sentence version of my
reply tends to be "No, Fortran 90 is more like a cross between Fortran
77 and Ada." Like most analogies, that one is far from perfect, but it
is about as well as I can do with that few words.
Gordon Sande
<am...@linuxchip.demon.co.uk.uk.uk> said:
There is a distinction to be made between what the standard
requires and what the various compilers offer. Some systems
are oriented to the ultimate SpecMark(??) benchmark figures
while others offer tightly monitored executions.
Subscript checking can be turned on for those systems. Some
even go the extra mile of offering checking for usage of
undefined (uninitialized) variables. Some undefineds can be
caught as a byproduct of flow checking at compile time but
others, like array elements, are only possible at run time.
Some "real" programmers disdain the use of such tools but others
are glad for all the aids that are available.
As with most groups there are subgroups. Some Fortran programmers
dismiss any notions of less than full exploitation of every last quirk
of the hardware and software of the day. Their equivalents in other
programming groups are probably the folks who ignore all interrupts.
The urban legends have the Fortran error of a DO loop that changed into
an assignment because of a typo changing a comma into a period and
a satellite was lost. For Ada it is a tossed interrupt that caused a
launch failure. Bad practice of one will always be inferior to good
practice of the other.
Nasser Abbasi
"Richard E Maine" <nos...@see.signature> wrote in message
news:1hfu968.1i5puf26uqbldN%nos...@see.signature...
.....
>"No, Fortran 90 is more like a cross between Fortran
> 77 and Ada." Like most analogies, that one is far from perfect, but it
> is about as well as I can do with that few words.
>
Well, at least one thing is common between Ada and Fortran: Both are case
INSENSITIVE.
I think this is a good thing, because I like to see the KEYWORDS in
uppercase. This seems to make the code more readable to me.
Nasser
Ed Falis
than most language comparison fests. You Fortran guys are presenting
mature, intelligent and interesting perspectives. Kudos to you.
- Ed
Ed Falis
<g.s...@worldnet.att.net> wrote:
> The urban legends have the Fortran error of a DO loop that changed into
> an assignment because of a typo changing a comma into a period and
> a satellite was lost. For Ada it is a tossed interrupt that caused a
> launch failure. Bad practice of one will always be inferior to good
> practice of the other.
In the Ariane 5 case, it wasn't the language, but mismanagement in
applying software appropriate to a launcher with different flight
parameters to a new one without review.
- Ed
glen herrmannsfeldt
(snip, someone wrote)
>> Is that through sequence association - i.e., I can assume (conceptually)
>> an EUIVALENCE of two reals, the real and imaginary part in that order, to
>> be in place for a complex variable?
(snip)
> However, essentially all of Fortran's rules have an "as if"
> clause somewhere in them. If the compiler is sufficiently
> clever (and can see enough of the whole program) it can do
> anything with complex variables. Keeping temporaries in
> registers and discarding them when they become dead is
> common practice and is standard conforming.
OK, but say for a certain program it is more efficient to store a
complex array with all the real parts followed by all the imaginary
parts, and the compiler figured this out. The "as if" rule would work
only if there was no other way for the program/programmer to discover
the change. If the array was in COMMON, EQUIVALENCEd, or passed to an
external routine, this optimization most likely couldn't be done.
Without any legal way to view the storage association, it would seem
possible to do it.
-- glen
J.F. Cornwall
Hence the urban legend part of the reference...
Jim
glen herrmannsfeldt
> Dick Hendrickson <dick.hen...@att.net> wrote:
>>There's a ambiguous "it" in those sentences. ;)
> Ah, Dick. You missed such a great opportunity to phrase that
> self-referentially as just "It is ambiguous." :-)
I was going to say:
"It depends on what the meaning of the word 'it' is."
-- glen
Gordon Sande
Is that English vrs French or Ada vrs Fortran? Of course it does not
matter as mismanagement transends both natural and formal languages
and is possible for both.
Gautier
> Well, at least one thing is common between Ada and Fortran: Both are case
> INSENSITIVE.
Two other points in common are readability (or, non-cryptic syntax) and (Fortran: 77+ ?)
full-bracketing (conditional or loop statements terminated by END). Both things are
extremely helpful for revising code, which is crucial for scientific programming, and
separate the pre- (Pascal, C) and post-1977 compiled languages.
G.
NB: For a direct answer, e-mail address on the Web site!
Gautier
> Well, at least one thing is common between Ada and Fortran: Both are case INSENSITIVE.
Two other points in common are readability (or, non-cryptic syntax) and (Fortran: 77+ ?)
full-bracketing (conditional or loop statements terminated by END). Both things are
extremely helpful for revising code, which is crucial for scientific programming, and
separate the pre- (Pascal, C) and post-1977 compiled languages.
G.
_______________________________________________________________
Ada programming -- http://www.mysunrise.ch/users/gdm/gsoft.htm
Richard E Maine
> Nasser Abbasi:
>
> > Well, at least one thing is common between Ada and Fortran: Both are
> > case INSENSITIVE.
>
> Two other points in common are readability (or, non-cryptic syntax) and
> (Fortran: 77+ ?) full-bracketing (conditional or loop statements
> terminated by END). Both things are extremely helpful for revising code,
> which is crucial for scientific programming, and separate the pre-
> (Pascal, C) and post-1977 compiled languages.
I had also noticed the similarity between Fortran 90 modules and Ada
packages. Not idenical by any means, but there are sure some
similarities.
And the possibility of specifying procedure arguments by keyword instead
of just positionally. You find that in some scripting languages. And you
find things like that in lots of other contexts, including the syntax
typically used to invoke compilers. But in compiled languages, it seems
like the feature is rare; it is shared by Fortran 90 and Ada, and then I
start slowing down a lot in naming compiled languaages in widespread use
that have it.
Dick Hendrickson
Dr. Adrian Wrigley wrote:
> On Wed, 24 May 2006 17:12:55 +0000, Dick Hendrickson wrote:
[snip, discussion mostly of subscript bounds checking and some
discussion of subroutine calling consistency]
> I think this is an area that Ada really shines. The standard
> requires numerous checks for consistency at both compile
> time and runtime. Versions of code that don't match properly
> can't be linked together or can't be run together (as appropriate).
> Using the language gives a feeling of integrity of coding,
> with mistakes often being caught very early on.
>
> Unfortunately, the language features for integrity cannot
> be added to an existing language without breaking old
> code. This is because the integrity features are often a result
> of prohibiting "dodgy" code, flawed syntax or misfeatures.
Yes, in Fortran 90 the decision was made to allow complete
compatability with existing standard conforming code. For
good or bad, old code written in the 60s dealt with 32,000
word memories and, as a result, the standard adopted
features that let memory be reused and viewed in different
ways. COMMON, EQUIVALENCE, the ability to magically reshape
arrays across the CALL boundary, alternate ENRTY points in
subroutines and functions all, in my opinion, trace their
ancestry to dealing with small memories and slow (or
nonexistent) rotating storage. Keeping those codes alive
required some compromises. The need for separate
compilation of 1,000,000 line programs and the use of
well tested existing libraries (often in C or assembly)
basically prevented Fortran from adopting strict CALL
interface rules. However, I think more and more
libraries are being retro-fitted with a clean module
interface where possible. So things are getting better.
There's no real excuse for writting a new program
without using modules to specify the interfaces and
this essentially guarantees that the compiler will
do the right thing. One serious practical problem
with large codes has been compilation cascades. Any
change to a low-level module almost always forced a
recompilation of everything that used the module, even
if the change had no effect on the interfaces. This
is mostly due to the way make interacts with the
commonest implementation of modules, I think. This
will be fixed (or at least changed ;) ) in F2008.
Dick Hendrickson
robin
news:pan.2006.05.24...@linuxchip.demon.co.uk.uk.uk...
That was not the case for Fortran.
Old Fortran codes can still run, even though the language
now provides the means for consistency checks.
> This is because the integrity features are often a result
> of prohibiting "dodgy" code, flawed syntax or misfeatures.
> The history of the C family of languages illustrates this.
> I'm not sure where modern Fortran sits in relation to
> its forbears in terms of safety and security though.
> It's noteworthy that Ada and Fortran are on convergent
> paths (modules, user defined types, templates etc).
>
> With array subscripts, an exception must be raised if the
> bounds are exceeded.
As is the case with PL/I (given that the programmer
has enabled that check).
> The same with arithmetic operations.
> (curiously, compiling Ada under gcc (GNAT), a compilation
> switch is needed to be standards compliant - a mistake:().
> The checks can be switched on and off in the source code
> as desired.
As is the case with PL/I.
robin
That wasn't the case. The code was reviewed,
and it was decided that the particular conversion
didn't require a check for overflow (even though
similar conversions in the vicinity had protection).
(This was a conversion from float to 16-bit integer).
Anyone experienced with real time programming
would have pointed out that it was a stupid thing to do.
robin
> robin wrote:
> > "Dick Hendrickson" <dick.hen...@att.net> wrote in message
> > news:PkHcg.90575$Fs1....@bgtnsc05-news.ops.worldnet.att.net...
> >
> >>Ada's is surely better. Knowing that a subscript has to be
> >>in range, because it's checked when a value is assigned to
> >>the subscript variable, has to be more efficient than what
> >>Fortran can do. In general, Fortran has to check the value
> >>of the subscripts on every array reference.
>
> > It can do this only if it is a compiler option.
> > It is not a feature the language.
>
> There's a ambiguous "it" in those sentences. ;)
>
> But, if "it" refers to Fortran, subscript bounds rules
> ARE a feature of the language.
Subscript bounds checking is not part of the Fortran language.
> You are NEVER allowed to
> execute an out-of-bounds array reference in a Fortran
> program. In practice, the historical run-time cost of
> checking bounds was [thought to be] too high, so compilers
> either didn't do it, or did it under some sort of command
> line option control.
But in some languages [PL/I included] bounds checking
is part of the language, and can be controlled by the programmer.
Subscript checking is an important part of any program.
> Dick Hendrickson
Nasser Abbasi
"robin" <rob...@bigpond.com> wrote in message
news:6H9dg.10258$S7....@news-server.bigpond.net.au...
> "Dick Hendrickson" <dick.hen...@att.net> wrote in message
> news:%P_cg.155733$eR6....@bgtnsc04-news.ops.worldnet.att.net...
>
>> robin wrote:
>> > "Dick Hendrickson" <dick.hen...@att.net> wrote in message
>> > news:PkHcg.90575$Fs1....@bgtnsc05-news.ops.worldnet.att.net...
>> >
>> >>Ada's is surely better. Knowing that a subscript has to be
>> >>in range, because it's checked when a value is assigned to
>> >>the subscript variable, has to be more efficient than what
>> >>Fortran can do. In general, Fortran has to check the value
>> >>of the subscripts on every array reference.
>>
>> > It can do this only if it is a compiler option.
>> > It is not a feature the language.
>>
>> There's a ambiguous "it" in those sentences. ;)
>>
>> But, if "it" refers to Fortran, subscript bounds rules
>> ARE a feature of the language.
>
> Subscript bounds checking is not part of the Fortran language.
>
I just did this simple test, declare an array and go overbound and see if we
get a run-time error:
----------------- FORTRAN 95 ------
$ g95 --version
G95 (GCC 4.0.2 (g95!) Mar 3 2006)
Copyright (C) 2002-2005 Free Software Foundation, Inc.
$ cat f.f90
PROGRAM MAIN
INTEGER A(10)
DO I=1,11
A(I)=0
END DO
END PROGRAM
$ g95 f.f90
$ ./a.exe
$ <------------------- NO runtime ERROR
---------------- ADA gnat2005 ----------
$ cat main.adb
procedure Main is
A : array( INTEGER RANGE 1..10) OF INTEGER;
BEGIN
FOR I IN 1..11 LOOP
A(I):=0;
END LOOP;
END Main;
gnatmake etc.....
successful compilation/build
$ ./main.exe
raised CONSTRAINT_ERROR : main.adb:6 index check failed <---- ERROR
Nasser