The answer to "Can Ada replace FORTRAN for numerical computation?

The answer to "Can Ada replace FORTRAN for numerical computation?

[Nasser M. Abbasi]

In 1980 there was a paper titled "Can Ada replace FORTRAN for numerical computation?"

ACM SIGPLAN Notices
Volume 16, Number 12, December, 1981


https://dl.acm.org/citation.cfm?id=954264

"
In July 1980, the proposed final form of the Ada programming
language was released by the U.S. Department of Defense [1]. Even
though Ada was not designed specifically for general numeric
scientific computation, nevertheless the question arises to whether
it is appropriate for this purpose. This question can best
be answered by consideration of the following question: Is Ada
a suitable replacement for the programming language FORTRAN? This
paper discusses those constructs of Ada which are pertinent to the
matter and are considered defective. It is noted that the array defects
are exceptionally critical, not providing needed capabilities
that exist in FORTRAN and have been extensively used for
  a quarter century."

I can't find free version of the paper, any one knows of one? but
there was more discussion on it here:

https://archive.org/stream/DTIC_ADA139224/DTIC_ADA139224_djvu.txt

(just search for string "can ada")

_But_ to answer the question in the title of the paper, and
after FORTY years, it is clear now that the answer is a
resounding NO.

Too bad, because Ada could have been best language for numerical
computation due to its strong typing. But its lack of support
for many things related to linear algebra and such, as discussed
in the above, Ada could not replace Fortran.

--Nasser

Re: The answer to "Can Ada replace FORTRAN for numerical computation?

[Simon Wright]

"Nasser M. Abbasi" <nma@12000.org> writes:

> In 1980 there was a paper titled "Can Ada replace FORTRAN for
> numerical computation?"
>
> ACM SIGPLAN Notices
> Volume 16, Number 12, December, 1981
>
>
> https://dl.acm.org/citation.cfm?id=954264
>
> "
> In July 1980, the proposed final form of the Ada programming
> language was released by the U.S. Department of Defense [1]. Even
> though Ada was not designed specifically for general numeric
> scientific computation, nevertheless the question arises to whether
> it is appropriate for this purpose. This question can best
> be answered by consideration of the following question: Is Ada
> a suitable replacement for the programming language FORTRAN? This
> paper discusses those constructs of Ada which are pertinent to the
> matter and are considered defective. It is noted that the array defects
> are exceptionally critical, not providing needed capabilities
> that exist in FORTRAN and have been extensively used for
>  a quarter century."
>
> I can't find free version of the paper, any one knows of one? but
> there was more discussion on it here:
>
> https://archive.org/stream/DTIC_ADA139224/DTIC_ADA139224_djvu.txt
>
> (just search for string "can ada")
>
> _But_ to answer the question in the title of the paper, and
> after FORTY years, it is clear now that the answer is a
> resounding NO.

I can't believe that the visible complaint (the ordering convention for
matrices, row- vs column-major) would seriously impact the mental
dexterity required to write mathematical code.

And now we have Convention (Fortran), which makes it not-too-hard to
interface to existing Fortran code.

Re: The answer to "Can Ada replace FORTRAN for numerical computation?

[Lucretia]

On Monday, 22 July 2019 06:53:06 UTC+1, Simon Wright  wrote:

> I can't believe that the visible complaint (the ordering convention for
> matrices, row- vs column-major) would seriously impact the mental
> dexterity required to write mathematical code.
> 
> And now we have Convention (Fortran), which makes it not-too-hard to
> interface to existing Fortran code.

Wouldn't Ada also require multi-dimensional slices? Something I've been wanting for a while, albeit in limited form, 2D/3D for images/textures.

Re: The answer to "Can Ada replace FORTRAN for numerical computation?

[Simon Wright]

Lucretia <laguest9000@googlemail.com> writes:

> On Monday, 22 July 2019 06:53:06 UTC+1, Simon Wright  wrote:
>
>> I can't believe that the visible complaint (the ordering convention for
>> matrices, row- vs column-major) would seriously impact the mental
>> dexterity required to write mathematical code.
>> 
>> And now we have Convention (Fortran), which makes it not-too-hard to
>> interface to existing Fortran code.
>
> Wouldn't Ada also require multi-dimensional slices? Something I've
> been wanting for a while, albeit in limited form, 2D/3D for
> images/textures.

I _think_ this is what the Fortran PACK/UNPACK & RESHAPE packages are
for; for example [1]. Interesting that the representation of the
matrices looks row-major!

The pre- and post-conditions might be a challenge.

[1] https://software.intel.com/en-us/fortran-compiler-developer-guide-and-reference-unpack

Re: The answer to "Can Ada replace FORTRAN for numerical computation?

[Lucretia]

On Monday, 22 July 2019 14:20:14 UTC+1, Simon Wright  wrote:
> >> I can't believe that the visible complaint (the ordering convention for
> >> matrices, row- vs column-major) would seriously impact the mental
> >> dexterity required to write mathematical code.
> >> 
> >> And now we have Convention (Fortran), which makes it not-too-hard to
> >> interface to existing Fortran code.
> >
> > Wouldn't Ada also require multi-dimensional slices? Something I've
> > been wanting for a while, albeit in limited form, 2D/3D for
> > images/textures.
> 
> I _think_ this is what the Fortran PACK/UNPACK & RESHAPE packages are
> for; for example [1]. Interesting that the representation of the
> matrices looks row-major!
> 
> The pre- and post-conditions might be a challenge.
> 
> [1] https://software.intel.com/en-us/fortran-compiler-developer-guide-and-reference-unpack

Something like:

M2 := M4 (1, 1 .. 2, 2); -- Makes a copy into the Matrix 2x2 type from a 4x4.

Re: The answer to "Can Ada replace FORTRAN for numerical computation?

[Brad Moore]

On Sunday, July 21, 2019 at 10:38:16 PM UTC-6, Nasser M. Abbasi wrote:
> In 1980 there was a paper titled "Can Ada replace FORTRAN for numerical computation?"
> 
> ACM SIGPLAN Notices
> Volume 16, Number 12, December, 1981
> 
> 
> https://dl.acm.org/citation.cfm?id=954264
> 
> "
> In July 1980, the proposed final form of the Ada programming
> language was released by the U.S. Department of Defense [1]. Even
> though Ada was not designed specifically for general numeric
> scientific computation, nevertheless the question arises to whether
> it is appropriate for this purpose. This question can best
> be answered by consideration of the following question: Is Ada
> a suitable replacement for the programming language FORTRAN? This
> paper discusses those constructs of Ada which are pertinent to the
> matter and are considered defective. It is noted that the array defects
> are exceptionally critical, not providing needed capabilities
> that exist in FORTRAN and have been extensively used for
>   a quarter century."
> 
> I can't find free version of the paper, any one knows of one? but
> there was more discussion on it here:
> 
> https://archive.org/stream/DTIC_ADA139224/DTIC_ADA139224_djvu.txt
> 
> (just search for string "can ada")
> 
> _But_ to answer the question in the title of the paper, and
> after FORTY years, it is clear now that the answer is a
> resounding NO.

If the goal was to have Ada replace Fortran, that was never a realistic goal to begin with, for many reasons. One being that there exists a lot of legacy Fortran code out there, and secondly I cannot think of any cases where language X replaced language Y. There will likely always be supporters existing for language Y, expecially if it better fits a particular niche.

> 
> Too bad, because Ada could have been best language for numerical
> computation due to its strong typing. But its lack of support
> for many things related to linear algebra and such, as discussed
> in the above, Ada could not replace Fortran.

That being said, a lot has happenned to Ada since Ada 83, when those articles were written, including support for things like linear algebra and such. See Ada.Numerics.Generic_Real_Arrays and Ada.Numerics. Ada.Numerics.Generic_Complex_Arrays, which include routes to Solve matrices, and perform various other operations on them.

e.g.

    --  Real_Matrix inversion and related operations

   function Solve (A : Real_Matrix; X : Real_Vector) return Real_Vector;
   function Solve (A, X : Real_Matrix) return Real_Matrix;
   function Inverse (A : Real_Matrix) return Real_Matrix;
   function Determinant (A : Real_Matrix) return Real'Base;

Brad

Re: The answer to "Can Ada replace FORTRAN for numerical computation?

[Jerry]

I use Ada every day as a FORTRAN replacement. It's absolutely wonderful.

Yes, it needs multidimensional array slicing etc. And FWIW, my FORTRAN experience was with FORTRAN 77 so I can't compare with later versions.

Jerry

Re: The answer to "Can Ada replace FORTRAN for numerical computation?

[Randy Brukardt]

"Lucretia" <laguest9000@googlemail.com> wrote in message 
news:28590d5c-d5f0-4322-9aa4-e1bb92419db3@googlegroups.com...
...
> Something like:
>
> M2 := M4 (1, 1 .. 2, 2); -- Makes a copy into the Matrix 2x2 type from a 
> 4x4.

This is no problem, of course. What is a problem is the fact that one can 
assign into these things and (especially) pass them as "in out" parameters. 
That causes overhead for all parameter passing of arrays, whether or not a 
multidimensional slice is ever actually used (the compiler cannot assume 
that array components are contiguous).

Array slices is one of the features I would remove from "Better Ada". Most 
of their utility comes from strings, and (modern) strings are not arrays in 
the first place. (I'd also get rid of arrays as a built-in type, making them 
a form of container.) A side-effect of that would be to get rid of the 
continuing discussion of this "obvious" extension that is way too expensive 
to have in Ada (or any language, for that matter). Subprograms can easily 
provide the "cheap" functionality, and no one really intends to use 
expensive code anyway.

                                       Randy.

Re: The answer to "Can Ada replace FORTRAN for numerical computation?

[Nasser M. Abbasi]

On 7/21/2019 11:38 PM, Nasser M. Abbasi wrote:
> In 1980 there was a paper titled "Can Ada replace FORTRAN for numerical computation?"
> 
> ACM SIGPLAN Notices
> Volume 16, Number 12, December, 1981
> 
> 
> https://dl.acm.org/citation.cfm?id=954264

FYI,

I found interesting entry about Ada here also.

Page 385, Computing methods in applied science and engineering.
SIAM, 1990. I found this at google books.

<https://books.google.com/books?id=2Q1-fWkMckkC>

I am not sure what they mean near the end below
about limitation in with regard to
dynamic typing and storage allocation. Any guess?

-----------------------------
"We have made preliminary experiments developing a
two-dimensional code for the Laplace equation based on
quartic finite elements using the Ada programming language.

This language has a remarkable power of expressiveness,
something vital to the rapid development of complicated software,
and its "strong typing" makes it easy to debug and modify.

In our experiments, the compile was able to find not just
typographical errors, but also conceptual errors in the
development of the code.

These attributes allowed our experimental code to be developed
surprisingly rapidly. Moreover, the "contract" style of
programming in Ada provides a good coding environment for
software development by a group.

Ada may provide a viable alternative to the current software
development techniques, and one that will lead to more
reliable software and involve less software development time.

However, the lack of universal availability of Ada
compilers prompted us to consider using other languages.

There are also significant limitation to Ada as a language
for scientific computation, in particular with regard to
dynamic typing and storage allocation.

Fortran 8X may ultimately provide much of what is needed
for well structured scientific computing code."
----------------

--Nasser

Re: The answer to "Can Ada replace FORTRAN for numerical computation?

[Shark8]

On Saturday, August 3, 2019 at 6:30:36 AM UTC-6, Nasser M. Abbasi wrote:
> There are also significant limitation to Ada as a language
> for scientific computation, in particular with regard to
> dynamic typing and storage allocation.

I think this is referring to things like dynamically-sized arrays, rather than "X is an integer there, now it's a String!" when talking about dynamic-typing, as it's obvious that the latter would obliviate the aforementioned properties of finding conceptual errors.

As to the storage-allocation, I suspect it is also referring to Ada arrays needing definite bounds in certain cases -- the ability to return properly-sized arrays from a function *should* be enough to ease this complaint *EXCEPT*, perhaps, when dealing with Very Large Arrays.

Re: The answer to "Can Ada replace FORTRAN for numerical computation?

[Optikos]

On Monday, August 5, 2019 at 9:35:10 AM UTC-5, Shark8 wrote:
> On Saturday, August 3, 2019 at 6:30:36 AM UTC-6, Nasser M. Abbasi wrote:
> > There are also significant limitation to Ada as a language
> > for scientific computation, in particular with regard to
> > dynamic typing and storage allocation.
> 
> I think this is referring to things like dynamically-sized arrays, rather than "X is an integer there, now it's
> a String!" when talking about dynamic-typing, as it's obvious that the latter would obliviate the
> aforementioned properties of finding conceptual errors.

But there are 2 usages of considering something an integer for the moment in a few lines of code.  One is to floor-truncate a floating- or fixed-point number to an integer; Ada supports syntax for this semantic meaning.  But another is to consider a floating-point representation as a machine-word to perform integer-based bit twiddling to conform the representation of the floating-point number to some machine requirements or machine representation that Ada's syntax and semantics lacks; pre-1995 Ada (the subject matter of the paper referenced) was abysmal at this commonplace use case in Fortran, PL/I, and C.  By pursuing the restrictions that Ada80 and Ada83 did, then Ada effectively bit off more than it could chew:  to always standardize a superset of any numeric-analysis semantics or system-programming semantics that IEEE or NIST or NSF or the supercomputing community could dream up—and then put it into practice with relatively minimal number of years of delay from that advance emerging from IEEE or NIST or the supercomputing community.  In that implicit bite-off-more-than-Ada-could-chew implied responsibility Ada failed miserably, whereas the loosey-goosey languages had no such impediment, hence Ada lost that mindshare pre-1995.  Post-1995 Ada was never able to reverse the already-cemented-in perception that such use-cases could be supported in Ada95 and later.

> As to the storage-allocation, I suspect it is also referring to Ada arrays needing definite bounds in
> certain cases -- the ability to return properly-sized arrays from a function *should* be enough to ease
> this complaint *EXCEPT*, perhaps, when dealing with Very Large Arrays.

Again, Ada has had a storage-pool wisdom at the heart of its storage allocation strategies, but pre-1995 Ada staunchly lacked PL/I's and Fortran's and C's ability to ecumenically reach out and read/write/manipulate some other language's in-memory storage format, as a I-got-you-covered system-programming duty.  Once that perception concrete cured into being rock-solid against Ada83, post-1995 Ada was never able to convince people whose mind was already made up to reconsider their now-misperception that such use-cases could now be supported.  And even post-1995 never fully embraced this idea of Ada being the über-Alles one-language-to-call-them-all lingua-franca eye-of-Sauron agenda that it could have (and to accomplish HOLWG's mission for Green) taken on.  The closest that any language has come to accomplishing this mission is Oxygene in the inter-language Elements Compiler from RemObjects Software LLC, which can be such an  über-Alles one-language-to-call-them-all lingua-franca eye-of-Sauron among Pascal, Java, C#, Swift, any JVM language (e.g., Kotlin), any .NET language (e.g., F#), and any WebAssembly language.  Microsoft's Xlang could (if every potential doesn't end in a dead end or failure) be a 2nd approximation of this über-Alles one-language-to-call-them-all lingua-franca eye-of-Sauron vision.  Had Jean Ichbiah or HOLWG specified late-1970s Steelman (or would ti have been a successor:  StainlessSteelMan*?) requirements for such an Elements Compiler or such an Xlang, Ada would have achieved all its goals of being the replacement of most other programming languages and most other programming languages would have died off by now.

Returning more narrowly to Fortan in numeric computing:
For all the advances that Ada made as being the one-language-to-rule-them-all replacement for all purposes, Ada failed to have an ABI-based ecumenism to be the lingua franca between disparate languages during the interim decades that it would take to retire all other languages' source code & usage.  Ichbiah's team (and HOLWG too) completely botched this need for an ABI-based ecumenism for Green/Ada to achieve its lofty goals of replacing all other programming languages in use at DoD & NATO (and by extension:  in use everywhere, such as including NIST, NSF, and the supercomputing community that were staunch Fortran hold-outs until Julia appeared in recent years, and now we have modern OO-Fortran and upstart Julia duking it out for which will be the dominant mainstream language in those communities henceforth).

* Btw, speaking of a metallic successor to Steelman, has anyone else noticed that Rust appears to be a mocking tongue-in-cheek ferrous reference in the Ironman and Steelman sets of requirements for safe computing?

Re: The answer to "Can Ada replace FORTRAN for numerical computation?

[Niklas Holsti]

On 19-08-05 20:15 , Optikos wrote:
> On Monday, August 5, 2019 at 9:35:10 AM UTC-5, Shark8 wrote:
>> On Saturday, August 3, 2019 at 6:30:36 AM UTC-6, Nasser M. Abbasi
>> wrote:
>>> There are also significant limitation to Ada as a language for
>>> scientific computation, in particular with regard to dynamic
>>> typing and storage allocation.
>>
>> I think this is referring to things like dynamically-sized arrays,
>> rather than "X is an integer there, now it's a String!" when
>> talking about dynamic-typing, as it's obvious that the latter would
>> obliviate the aforementioned properties of finding conceptual
>> errors.
>
> But there are 2 usages of considering something an integer for the
> moment in a few lines of code.  One is to floor-truncate a floating-
> or fixed-point number to an integer; Ada supports syntax for this
> semantic meaning.

Yes of course.

> But another is to consider a floating-point
> representation as a machine-word to perform integer-based bit
> twiddling to conform the representation of the floating-point number
> to some machine requirements or machine representation that Ada's
> syntax and semantics lacks; pre-1995 Ada (the subject matter of the
> paper referenced) was abysmal at this commonplace use case in
> Fortran, PL/I, and C.

No, record types with representation clauses plus Unchecked_Conversion 
were fully able to handle this case, already in Ada 83.

>> As to the storage-allocation, I suspect it is also referring to Ada
>> arrays needing definite bounds in certain cases -- the ability to
>> return properly-sized arrays from a function *should* be enough to
>> ease this complaint *EXCEPT*, perhaps, when dealing with Very Large
>> Arrays.

They may also have been scared by the "Unchecked" in 
Unchecked_Deallocation. The identifier "free" is so much more friendly 
and safe-sounding...

> Again, Ada has had a storage-pool wisdom at the heart of its storage
> allocation strategies, but pre-1995 Ada staunchly lacked PL/I's and
> Fortran's and C's ability to ecumenically reach out and
> read/write/manipulate some other language's in-memory storage format,
> as a I-got-you-covered system-programming duty.

I doubt your statement. There is nothing in Fortran or C that supports 
"other languages' formats", and you can do any format manipulations you 
want with Ada 83 as well as with Fortran or C. Please show a 
counter-example if you insist on this point.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: The answer to "Can Ada replace FORTRAN for numerical computation?

[Optikos]

On Wednesday, August 7, 2019 at 1:35:33 AM UTC-5, Niklas Holsti wrote:
> On 19-08-05 20:15 , Optikos wrote:
> > On Monday, August 5, 2019 at 9:35:10 AM UTC-5, Shark8 wrote:
> >> On Saturday, August 3, 2019 at 6:30:36 AM UTC-6, Nasser M. Abbasi
> >> wrote:
> >>> There are also significant limitation to Ada as a language for
> >>> scientific computation, in particular with regard to dynamic
> >>> typing and storage allocation.
> >>
> >> I think this is referring to things like dynamically-sized arrays,
> >> rather than "X is an integer there, now it's a String!" when
> >> talking about dynamic-typing, as it's obvious that the latter would
> >> obliviate the aforementioned properties of finding conceptual
> >> errors.
> >
> > But there are 2 usages of considering something an integer for the
> > moment in a few lines of code.  One is to floor-truncate a floating-
> > or fixed-point number to an integer; Ada supports syntax for this
> > semantic meaning.
> 
> Yes of course.
> 
> > But another is to consider a floating-point
> > representation as a machine-word to perform integer-based bit
> > twiddling to conform the representation of the floating-point number
> > to some machine requirements or machine representation that Ada's
> > syntax and semantics lacks; pre-1995 Ada (the subject matter of the
> > paper referenced) was abysmal at this commonplace use case in
> > Fortran, PL/I, and C.
> 
> No, record types with representation clauses plus Unchecked_Conversion 
> were fully able to handle this case, already in Ada 83.
> 
> >> As to the storage-allocation, I suspect it is also referring to Ada
> >> arrays needing definite bounds in certain cases -- the ability to
> >> return properly-sized arrays from a function *should* be enough to
> >> ease this complaint *EXCEPT*, perhaps, when dealing with Very Large
> >> Arrays.
> 
> They may also have been scared by the "Unchecked" in 
> Unchecked_Deallocation. The identifier "free" is so much more friendly 
> and safe-sounding...
> 
> > Again, Ada has had a storage-pool wisdom at the heart of its storage
> > allocation strategies, but pre-1995 Ada staunchly lacked PL/I's and
> > Fortran's and C's ability to ecumenically reach out and
> > read/write/manipulate some other language's in-memory storage format,
> > as a I-got-you-covered system-programming duty.
> 
> I doubt your statement. …, and you can do any format manipulations you 
> want with Ada 83 as well as with Fortran or C. Please show a 
> counter-example if you insist on this point.

https://gcc.gnu.org/onlinedocs/gcc-4.8.1/gnat_ugn_unw/Representation-Clauses.html

Before we dive into a counter-example in source code for various languages, let's start, as linked above, with the Ada community speaking for itself regarding Ada83's lackluster (i.e., lack of clear mandate regarding) representation clauses.  Indeed, as mentioned in recent months on c.l.a., Janus/Ada to this day does not fully support some semantics of representation clauses, even after all these decades.  A programming language is not what merely is on paper in its standard, especially when noncompliance with the content of the standard is overtly permitted by the (excessively-)permissive specification of the language in the standard.

(And not all the tarnish of representation clauses was polished off by Ada95 either, according to the commentary linked above.)

> There is nothing in Fortran or C that supports "other languages' formats"

Again, a language is more than merely being a bag of features overtly stated via extant text in its standard or specification •document•.  Indeed, Fortran, PL/I, and C are famous & popular (and should I say, notorious & infamous) for the breadth of their permissiveness regarding in-memory layout, and lack of staunch regulation of semantics in general.  Hence, what is elided from being stated in the standard's extant text in order to ••enact the permissiveness•• is far more important on this inter-language use-case than any word, clause, sentence, or paragraph that overtly appears as text in the standard or specification of the loosey-goosey languages.

Furthermore, your statement is clearly factually incorrect regarding Fortran 2003's overtly-specified feature-set for inter-oping with C •directly• without the need for a Fortran wrapper anymore, which was the technique that was extant at the time of the 1980 paper that started this whole thread.  (These same low-level-layout system-programming techniques in Fortran were utilized by Prime Computer back in the day that they wrote whole operating systems in Fortran IV as a poor-man's system-programming language prior to switching to PL/P, which was their dialect of Multics PL/1.)  For a summary of Fortran 2003's standardized intimate binding with C nowadays, please see slide 10 of:
https://ModelingGuru.nasa.gov/servlet/JiveServlet/previewBody/1361-102-6-1755/Introduction_F2003.pdf

And of course we could dive into the Fortran standard documents themselves regarding their evermore-extensive inter-op with C:
https://gcc.gnu.org/wiki/GFortranStandards

Re: The answer to "Can Ada replace FORTRAN for numerical computation?

[Norman Worth]

Randy Brukardt wrote:
> "Lucretia" <laguest9000@googlemail.com> wrote in message
> news:28590d5c-d5f0-4322-9aa4-e1bb92419db3@googlegroups.com...
> ...
>> Something like:
>>
>> M2 := M4 (1, 1 .. 2, 2); -- Makes a copy into the Matrix 2x2 type from a
>> 4x4.
> 
> This is no problem, of course. What is a problem is the fact that one can
> assign into these things and (especially) pass them as "in out" parameters.
> That causes overhead for all parameter passing of arrays, whether or not a
> multidimensional slice is ever actually used (the compiler cannot assume
> that array components are contiguous).
> 
> Array slices is one of the features I would remove from "Better Ada". Most
> of their utility comes from strings, and (modern) strings are not arrays in
> the first place. (I'd also get rid of arrays as a built-in type, making them
> a form of container.) A side-effect of that would be to get rid of the
> continuing discussion of this "obvious" extension that is way too expensive
> to have in Ada (or any language, for that matter). Subprograms can easily
> provide the "cheap" functionality, and no one really intends to use
> expensive code anyway.
> 
>                                         Randy.
> 
> 
I agree that arrays would probably work better as containers, but array 
slices are very handy in a number of cases when you need to copy part of 
an array or restrict the view of the array.  But then slices would 
probably work better as container functions too.

Re: The answer to "Can Ada replace FORTRAN for numerical computation?

[Dmitry A. Kazakov]

On 2019-08-15 18:45, Norman Worth wrote:

> I agree that arrays would probably work better as containers, but array 
> slices are very handy in a number of cases when you need to copy part of 
> an array or restrict the view of the array.  But then slices would 
> probably work better as container functions too.

Rather containers would work better as arrays and slices of like String 
vs Unbounded_String.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: The answer to "Can Ada replace FORTRAN for numerical computation?

[Norman Worth]

Dmitry A. Kazakov wrote:
> On 2019-08-15 18:45, Norman Worth wrote:
> 
>> I agree that arrays would probably work better as containers, but 
>> array slices are very handy in a number of cases when you need to copy 
>> part of an array or restrict the view of the array.  But then slices 
>> would probably work better as container functions too.
> 
> Rather containers would work better as arrays and slices of like String 
> vs Unbounded_String.
> 
Of course we can have (and sometimes do have) arrays of containers.

Re: The answer to "Can Ada replace FORTRAN for numerical computation?

[Norman Worth]

Optikos wrote:
> On Wednesday, August 7, 2019 at 1:35:33 AM UTC-5, Niklas Holsti wrote:
>> On 19-08-05 20:15 , Optikos wrote:
>>> On Monday, August 5, 2019 at 9:35:10 AM UTC-5, Shark8 wrote:
>>>> On Saturday, August 3, 2019 at 6:30:36 AM UTC-6, Nasser M. Abbasi
>>>> wrote:
>>>>> There are also significant limitation to Ada as a language for
>>>>> scientific computation, in particular with regard to dynamic
>>>>> typing and storage allocation.
>>>>
>>>> I think this is referring to things like dynamically-sized arrays,
>>>> rather than "X is an integer there, now it's a String!" when
>>>> talking about dynamic-typing, as it's obvious that the latter would
>>>> obliviate the aforementioned properties of finding conceptual
>>>> errors.
>>>
>>> But there are 2 usages of considering something an integer for the
>>> moment in a few lines of code.  One is to floor-truncate a floating-
>>> or fixed-point number to an integer; Ada supports syntax for this
>>> semantic meaning.
>>
>> Yes of course.
>>
>>> But another is to consider a floating-point
>>> representation as a machine-word to perform integer-based bit
>>> twiddling to conform the representation of the floating-point number
>>> to some machine requirements or machine representation that Ada's
>>> syntax and semantics lacks; pre-1995 Ada (the subject matter of the
>>> paper referenced) was abysmal at this commonplace use case in
>>> Fortran, PL/I, and C.
>>
>> No, record types with representation clauses plus Unchecked_Conversion
>> were fully able to handle this case, already in Ada 83.
>>
>>>> As to the storage-allocation, I suspect it is also referring to Ada
>>>> arrays needing definite bounds in certain cases -- the ability to
>>>> return properly-sized arrays from a function *should* be enough to
>>>> ease this complaint *EXCEPT*, perhaps, when dealing with Very Large
>>>> Arrays.
>>
>> They may also have been scared by the "Unchecked" in
>> Unchecked_Deallocation. The identifier "free" is so much more friendly
>> and safe-sounding...
>>
>>> Again, Ada has had a storage-pool wisdom at the heart of its storage
>>> allocation strategies, but pre-1995 Ada staunchly lacked PL/I's and
>>> Fortran's and C's ability to ecumenically reach out and
>>> read/write/manipulate some other language's in-memory storage format,
>>> as a I-got-you-covered system-programming duty.
>>
>> I doubt your statement. …, and you can do any format manipulations you
>> want with Ada 83 as well as with Fortran or C. Please show a
>> counter-example if you insist on this point.
> 
> https://gcc.gnu.org/onlinedocs/gcc-4.8.1/gnat_ugn_unw/Representation-Clauses.html
> 
> Before we dive into a counter-example in source code for various languages, let's start, as linked above, with the Ada community speaking for itself regarding Ada83's lackluster (i.e., lack of clear mandate regarding) representation clauses.  Indeed, as mentioned in recent months on c.l.a., Janus/Ada to this day does not fully support some semantics of representation clauses, even after all these decades.  A programming language is not what merely is on paper in its standard, especially when noncompliance with the content of the standard is overtly permitted by the (excessively-)permissive specification of the language in the standard.
> 
> (And not all the tarnish of representation clauses was polished off by Ada95 either, according to the commentary linked above.)
> 
>> There is nothing in Fortran or C that supports "other languages' formats"
> 
> Again, a language is more than merely being a bag of features overtly stated via extant text in its standard or specification •document•.  Indeed, Fortran, PL/I, and C are famous & popular (and should I say, notorious & infamous) for the breadth of their permissiveness regarding in-memory layout, and lack of staunch regulation of semantics in general.  Hence, what is elided from being stated in the standard's extant text in order to ••enact the permissiveness•• is far more important on this inter-language use-case than any word, clause, sentence, or paragraph that overtly appears as text in the standard or specification of the loosey-goosey languages.
> 
> Furthermore, your statement is clearly factually incorrect regarding Fortran 2003's overtly-specified feature-set for inter-oping with C •directly• without the need for a Fortran wrapper anymore, which was the technique that was extant at the time of the 1980 paper that started this whole thread.  (These same low-level-layout system-programming techniques in Fortran were utilized by Prime Computer back in the day that they wrote whole operating systems in Fortran IV as a poor-man's system-programming language prior to switching to PL/P, which was their dialect of Multics PL/1.)  For a summary of Fortran 2003's standardized intimate binding with C nowadays, please see slide 10 of:
> https://ModelingGuru.nasa.gov/servlet/JiveServlet/previewBody/1361-102-6-1755/Introduction_F2003.pdf
> 
> And of course we could dive into the Fortran standard documents themselves regarding their evermore-extensive inter-op with C:
> https://gcc.gnu.org/wiki/GFortranStandards
> 
Some ancient history.  In olden times there were, by edict of the great 
lord IBM, two kinds of computers: one kind for scientific us, like the 
IBM 704, and one kind for business use, like the 702. (The fact that 
people paid little attention to the edict and used whatever worked is 
beside the point.)  Most programming was done in machine language (octal 
code).  Then assemblers and assembly language were developed, which 
greatly eased programming and increased both productivity and accuracy. 
But assembly language was still a specialized skill limited to an elite 
priesthood.  Someone thought IBM could make more money if programming 
were still easier.  A higher level language with machine translation to 
octal code was suggested.  But the priesthood objected that they could 
write programs which would run as efficiently as possible, something 
that no machine translator could do.  After all, speed and memory usage 
were critical for scientific work.

Thus came about FORTRAN, which has as a design criterion that the code 
it produced be at least as efficient as the code produced by an expert 
assembly language programmer.  At least through Fortran 77, efficiency 
was always the primary objective for the Fortran language and its 
compilers.  Most compilers (not all) were pretty good at it, and Fortran 
gained a reputation as the number crunching language.  Depending on the 
computer and the compiler, it may or may not have deserved it.

This was not the case with Ada, which had much broader objectives.  The 
main ideas of Ada were reliability and applicability to large systems. 
That has some costs.  Even with internal checks turned off, Ada has 
always been a little slower than Fortran at number crunching.  It hasn't 
been enough to make much difference, but its there.  But Ada is 
generally more safer, more reliable, and arguably more versatile and 
easier to program, especially in large systems.

As for the complaints listed, although Ada's strong typing requires more 
planning, most people look at it as an asset.  As for creating 
dynamically sized arrays and returning them from procedures, Ada can do 
that, although it is more verbose and takes a bit more planning:

with ada.text_io; use ada.text_io;
procedure ar is
    type a is array(integer range <>) of integer;
    type ap is access a;
    P : ap;
    procedure da (i : in integer; j : in integer; p : out ap) is
       begin
	  p := new a(1..i);
       p.all := (others => j);
	  end;
    begin
    da (4, 10, P);
    put_line (P(4)'image);
    da (10, 4, P);
    put_line (P(10)'image);
    end;

(Note that since Ada does not have a "free" verb, memory management is a 
bit more complicated, requiring "uncontrolled deallocation", which is 
type sensitive, to explicitly deallocate the memory for each instance of 
P.  But Ada will take care of deallocation nicely when P goes out of 
scope at the end of the procedure.)

Re: The answer to "Can Ada replace FORTRAN for numerical computation?

[Dmitry A. Kazakov]

On 2019-08-16 20:29, Norman Worth wrote:
> Dmitry A. Kazakov wrote:
>> On 2019-08-15 18:45, Norman Worth wrote:
>>
>>> I agree that arrays would probably work better as containers, but 
>>> array slices are very handy in a number of cases when you need to 
>>> copy part of an array or restrict the view of the array.  But then 
>>> slices would probably work better as container functions too.
>>
>> Rather containers would work better as arrays and slices of like 
>> String vs Unbounded_String.
>>
> Of course we can have (and sometimes do have) arrays of containers.

Jagged and n-D arrays cover all cases. Containers without array 
interface are usually no containers at all, e.g. lists.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: The answer to "Can Ada replace FORTRAN for numerical computation?

[Jeffrey R. Carter]

On 8/16/19 9:11 PM, Norman Worth wrote:
> 
> with ada.text_io; use ada.text_io;
> procedure ar is
>     type a is array(integer range <>) of integer;
>     type ap is access a;
>     P : ap;
>     procedure da (i : in integer; j : in integer; p : out ap) is
>        begin
>        p := new a(1..i);
>        p.all := (others => j);
>        end;
>     begin
>     da (4, 10, P);
>     put_line (P(4)'image);
>     da (10, 4, P);
>     put_line (P(10)'image);
>     end;
> 
> (Note that since Ada does not have a "free" verb, memory management is a bit 
> more complicated, requiring "uncontrolled deallocation", which is type 
> sensitive, to explicitly deallocate the memory for each instance of P.  But Ada 
> will take care of deallocation nicely when P goes out of scope at the end of the 
> procedure.)

Like 99.9% of all problems, we can do the same thing without writing "access" or 
using Unchecked_Deallocation. Clearer and safer.

-- 
Jeff Carter
"Crucifixion's a doddle."
Monty Python's Life of Brian
82

Re: The answer to "Can Ada replace FORTRAN for numerical computation?

[robin.vowels]

On Saturday, August 17, 2019 at 5:11:09 AM UTC+10, Norman Worth wrote:
> Optikos wrote:
> > On Wednesday, August 7, 2019 at 1:35:33 AM UTC-5, Niklas Holsti wrote:
> >> On 19-08-05 20:15 , Optikos wrote:
> >>> On Monday, August 5, 2019 at 9:35:10 AM UTC-5, Shark8 wrote:
> >>>> On Saturday, August 3, 2019 at 6:30:36 AM UTC-6, Nasser M. Abbasi
> >>>> wrote:
> >>>>> There are also significant limitation to Ada as a language for
> >>>>> scientific computation, in particular with regard to dynamic
> >>>>> typing and storage allocation.
> >>>>
> >>>> I think this is referring to things like dynamically-sized arrays,
> >>>> rather than "X is an integer there, now it's a String!" when
> >>>> talking about dynamic-typing, as it's obvious that the latter would
> >>>> obliviate the aforementioned properties of finding conceptual
> >>>> errors.
> >>>
> >>> But there are 2 usages of considering something an integer for the
> >>> moment in a few lines of code.  One is to floor-truncate a floating-
> >>> or fixed-point number to an integer; Ada supports syntax for this
> >>> semantic meaning.
> >>
> >> Yes of course.
> >>
> >>> But another is to consider a floating-point
> >>> representation as a machine-word to perform integer-based bit
> >>> twiddling to conform the representation of the floating-point number
> >>> to some machine requirements or machine representation that Ada's
> >>> syntax and semantics lacks; pre-1995 Ada (the subject matter of the
> >>> paper referenced) was abysmal at this commonplace use case in
> >>> Fortran, PL/I, and C.
> >>
> >> No, record types with representation clauses plus Unchecked_Conversion
> >> were fully able to handle this case, already in Ada 83.
> >>
> >>>> As to the storage-allocation, I suspect it is also referring to Ada
> >>>> arrays needing definite bounds in certain cases -- the ability to
> >>>> return properly-sized arrays from a function *should* be enough to
> >>>> ease this complaint *EXCEPT*, perhaps, when dealing with Very Large
> >>>> Arrays.
> >>
> >> They may also have been scared by the "Unchecked" in
> >> Unchecked_Deallocation. The identifier "free" is so much more friendly
> >> and safe-sounding...
> >>
> >>> Again, Ada has had a storage-pool wisdom at the heart of its storage
> >>> allocation strategies, but pre-1995 Ada staunchly lacked PL/I's and
> >>> Fortran's and C's ability to ecumenically reach out and
> >>> read/write/manipulate some other language's in-memory storage format,
> >>> as a I-got-you-covered system-programming duty.
> >>
> >> I doubt your statement. …, and you can do any format manipulations you
> >> want with Ada 83 as well as with Fortran or C. Please show a
> >> counter-example if you insist on this point.
> > 
> > https://gcc.gnu.org/onlinedocs/gcc-4.8.1/gnat_ugn_unw/Representation-Clauses.html
> > 
> > Before we dive into a counter-example in source code for various languages, let's start, as linked above, with the Ada community speaking for itself regarding Ada83's lackluster (i.e., lack of clear mandate regarding) representation clauses.  Indeed, as mentioned in recent months on c.l.a., Janus/Ada to this day does not fully support some semantics of representation clauses, even after all these decades.  A programming language is not what merely is on paper in its standard, especially when noncompliance with the content of the standard is overtly permitted by the (excessively-)permissive specification of the language in the standard.
> > 
> > (And not all the tarnish of representation clauses was polished off by Ada95 either, according to the commentary linked above.)
> > 
> >> There is nothing in Fortran or C that supports "other languages' formats"
> > 
> > Again, a language is more than merely being a bag of features overtly stated via extant text in its standard or specification •document•.  Indeed, Fortran, PL/I, and C are famous & popular (and should I say, notorious & infamous) for the breadth of their permissiveness regarding in-memory layout, and lack of staunch regulation of semantics in general.  Hence, what is elided from being stated in the standard's extant text in order to ••enact the permissiveness•• is far more important on this inter-language use-case than any word, clause, sentence, or paragraph that overtly appears as text in the standard or specification of the loosey-goosey languages.
> > 
> > Furthermore, your statement is clearly factually incorrect regarding Fortran 2003's overtly-specified feature-set for inter-oping with C •directly• without the need for a Fortran wrapper anymore, which was the technique that was extant at the time of the 1980 paper that started this whole thread.  (These same low-level-layout system-programming techniques in Fortran were utilized by Prime Computer back in the day that they wrote whole operating systems in Fortran IV as a poor-man's system-programming language prior to switching to PL/P, which was their dialect of Multics PL/1.)  For a summary of Fortran 2003's standardized intimate binding with C nowadays, please see slide 10 of:
> > https://ModelingGuru.nasa.gov/servlet/JiveServlet/previewBody/1361-102-6-1755/Introduction_F2003.pdf
> > 
> > And of course we could dive into the Fortran standard documents themselves regarding their evermore-extensive inter-op with C:
> > https://gcc.gnu.org/wiki/GFortranStandards
> > 
> Some ancient history.  In olden times there were, by edict of the great 
> lord IBM, two kinds of computers: one kind for scientific us, like the 
> IBM 704, and one kind for business use, like the 702. (The fact that 
> people paid little attention to the edict and used whatever worked is 
> beside the point.)  Most programming was done in machine language (octal 
> code).  Then assemblers and assembly language were developed, which 
> greatly eased programming and increased both productivity and accuracy. 
> But assembly language was still a specialized skill limited to an elite 
> priesthood.  Someone thought IBM could make more money if programming 
> were still easier.  A higher level language with machine translation to 
> octal code was suggested.  But the priesthood objected that they could 
> write programs which would run as efficiently as possible, something 
> that no machine translator could do.  After all, speed and memory usage 
> were critical for scientific work.
> 
> Thus came about FORTRAN, which has as a design criterion that the code 
> it produced be at least as efficient as the code produced by an expert 
> assembly language programmer.

It could come close, but, in general, not equal.

The "quest" for speed meant that few internal checks
were provided -- in particular, array bounds checking.
If some computational error occurred, such as division
by zero, overflow, etc, the program merely crashed,
with little or no indication where the error occurred.
The outcome was wasted runs, that effectively lost
any advantages a good compiler might have in terms of
the speed of its compiled programs.

>  At least through Fortran 77, efficiency 
> was always the primary objective for the Fortran language and its 
> compilers.  Most compilers (not all) were pretty good at it, and Fortran 
> gained a reputation as the number crunching language.  Depending on the 
> computer and the compiler, it may or may not have deserved it.
> 
> This was not the case with Ada, which had much broader objectives.  The 
> main ideas of Ada were reliability and applicability to large systems. 
> That has some costs.  Even with internal checks turned off, Ada has 
> always been a little slower than Fortran at number crunching.  It hasn't 
> been enough to make much difference, but its there.  But Ada is 
> generally more safer, more reliable, and arguably more versatile and 
> easier to program, especially in large systems.
> 
> As for the complaints listed, although Ada's strong typing requires more 
> planning, most people look at it as an asset.  As for creating 
> dynamically sized arrays and returning them from procedures, Ada can do 
> that, although it is more verbose and takes a bit more planning:
> 
> with ada.text_io; use ada.text_io;
> procedure ar is
>     type a is array(integer range <>) of integer;
>     type ap is access a;
>     P : ap;
>     procedure da (i : in integer; j : in integer; p : out ap) is
>        begin
> 	  p := new a(1..i);
>        p.all := (others => j);
> 	  end;
>     begin
>     da (4, 10, P);
>     put_line (P(4)'image);
>     da (10, 4, P);
>     put_line (P(10)'image);
>     end;
> 
> (Note that since Ada does not have a "free" verb, memory management is a 
> bit more complicated, requiring "uncontrolled deallocation", which is 
> type sensitive, to explicitly deallocate the memory for each instance of 
> P.  But Ada will take care of deallocation nicely when P goes out of 
> scope at the end of the procedure.)

Re: The answer to "Can Ada replace FORTRAN for numerical computation?

[Norman Worth]

Dmitry A. Kazakov wrote:
> On 2019-08-16 20:29, Norman Worth wrote:
>> Dmitry A. Kazakov wrote:
>>> On 2019-08-15 18:45, Norman Worth wrote:
>>>
>>>> I agree that arrays would probably work better as containers, but 
>>>> array slices are very handy in a number of cases when you need to 
>>>> copy part of an array or restrict the view of the array.  But then 
>>>> slices would probably work better as container functions too.
>>>
>>> Rather containers would work better as arrays and slices of like 
>>> String vs Unbounded_String.
>>>
>> Of course we can have (and sometimes do have) arrays of containers.
> 
> Jagged and n-D arrays cover all cases. Containers without array 
> interface are usually no containers at all, e.g. lists.
> 
I don't recommend the things I show in the example.  Problem permitting, 
anything else is better.  But in those rare cases where it might be 
necessary, it is available and it works, in a messy sort of way.