From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Received: by 2002:aed:22d3:: with SMTP id q19mr9719661qtc.101.1566009532565; Fri, 16 Aug 2019 19:38:52 -0700 (PDT) X-Received: by 2002:a9d:7aa:: with SMTP id 39mr9539822oto.178.1566009532289; Fri, 16 Aug 2019 19:38:52 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!weretis.net!feeder6.news.weretis.net!feeder.usenetexpress.com!feeder-in1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!f14no7935591qtq.0!news-out.google.com!d29ni1807qtg.1!nntp.google.com!f14no7935589qtq.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Fri, 16 Aug 2019 19:38:51 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=202.67.103.232; posting-account=S_MdrwoAAAD7T2pxG2e393dk6y0tc0Le NNTP-Posting-Host: 202.67.103.232 References: <3862f4a3-d3b2-4959-b6f4-08086738df2c@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <0e7c7873-3f95-41c8-b91b-35e3370de704@googlegroups.com> Subject: Re: The answer to "Can Ada replace FORTRAN for numerical computation? From: robin.vowels@gmail.com Injection-Date: Sat, 17 Aug 2019 02:38:52 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader01.eternal-september.org comp.lang.ada:57072 Date: 2019-08-16T19:38:51-07:00 List-Id: 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. =E2=80=A6, and you can do any format manipulat= ions you > >> want with Ada 83 as well as with Fortran or C. Please show a > >> counter-example if you insist on this point. > >=20 > > https://gcc.gnu.org/onlinedocs/gcc-4.8.1/gnat_ugn_unw/Representation-Cl= auses.html > >=20 > > Before we dive into a counter-example in source code for various langua= ges, let's start, as linked above, with the Ada community speaking for itse= lf regarding Ada83's lackluster (i.e., lack of clear mandate regarding) rep= resentation clauses. Indeed, as mentioned in recent months on c.l.a., Janu= s/Ada to this day does not fully support some semantics of representation c= lauses, even after all these decades. A programming language is not what m= erely is on paper in its standard, especially when noncompliance with the c= ontent of the standard is overtly permitted by the (excessively-)permissive= specification of the language in the standard. > >=20 > > (And not all the tarnish of representation clauses was polished off by = Ada95 either, according to the commentary linked above.) > >=20 > >> There is nothing in Fortran or C that supports "other languages' forma= ts" > >=20 > > Again, a language is more than merely being a bag of features overtly s= tated via extant text in its standard or specification =E2=80=A2document=E2= =80=A2. Indeed, Fortran, PL/I, and C are famous & popular (and should I sa= y, 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 or= der to =E2=80=A2=E2=80=A2enact the permissiveness=E2=80=A2=E2=80=A2 is far = more important on this inter-language use-case than any word, clause, sente= nce, or paragraph that overtly appears as text in the standard or specifica= tion of the loosey-goosey languages. > >=20 > > Furthermore, your statement is clearly factually incorrect regarding Fo= rtran 2003's overtly-specified feature-set for inter-oping with C =E2=80=A2= directly=E2=80=A2 without the need for a Fortran wrapper anymore, which was= the technique that was extant at the time of the 1980 paper that started t= his whole thread. (These same low-level-layout system-programming techniqu= es in Fortran were utilized by Prime Computer back in the day that they wro= te 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 > >=20 > > And of course we could dive into the Fortran standard documents themsel= ves regarding their evermore-extensive inter-op with C: > > https://gcc.gnu.org/wiki/GFortranStandards > >=20 > Some ancient history. In olden times there were, by edict of the great= =20 > lord IBM, two kinds of computers: one kind for scientific us, like the=20 > IBM 704, and one kind for business use, like the 702. (The fact that=20 > people paid little attention to the edict and used whatever worked is=20 > beside the point.) Most programming was done in machine language (octal= =20 > code). Then assemblers and assembly language were developed, which=20 > greatly eased programming and increased both productivity and accuracy.= =20 > But assembly language was still a specialized skill limited to an elite= =20 > priesthood. Someone thought IBM could make more money if programming=20 > were still easier. A higher level language with machine translation to= =20 > octal code was suggested. But the priesthood objected that they could=20 > write programs which would run as efficiently as possible, something=20 > that no machine translator could do. After all, speed and memory usage= =20 > were critical for scientific work. >=20 > Thus came about FORTRAN, which has as a design criterion that the code=20 > it produced be at least as efficient as the code produced by an expert=20 > 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=20 > was always the primary objective for the Fortran language and its=20 > compilers. Most compilers (not all) were pretty good at it, and Fortran= =20 > gained a reputation as the number crunching language. Depending on the= =20 > computer and the compiler, it may or may not have deserved it. >=20 > This was not the case with Ada, which had much broader objectives. The= =20 > main ideas of Ada were reliability and applicability to large systems.=20 > That has some costs. Even with internal checks turned off, Ada has=20 > always been a little slower than Fortran at number crunching. It hasn't= =20 > been enough to make much difference, but its there. But Ada is=20 > generally more safer, more reliable, and arguably more versatile and=20 > easier to program, especially in large systems. >=20 > As for the complaints listed, although Ada's strong typing requires more= =20 > planning, most people look at it as an asset. As for creating=20 > dynamically sized arrays and returning them from procedures, Ada can do= =20 > that, although it is more verbose and takes a bit more planning: >=20 > 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 :=3D new a(1..i); > p.all :=3D (others =3D> j); > end; > begin > da (4, 10, P); > put_line (P(4)'image); > da (10, 4, P); > put_line (P(10)'image); > end; >=20 > (Note that since Ada does not have a "free" verb, memory management is a= =20 > bit more complicated, requiring "uncontrolled deallocation", which is=20 > type sensitive, to explicitly deallocate the memory for each instance of= =20 > P. But Ada will take care of deallocation nicely when P goes out of=20 > scope at the end of the procedure.)