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.7 required=5.0 tests=BAYES_00,INVALID_DATE, MSGID_SHORT,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site petsd.UUCP Path: utzoo!watmath!clyde!cbosgd!cbdkc1!desoto!packard!hoxna!houxm!vax135!petsd!joe From: joe@petsd.UUCP (Joe Orost) Newsgroups: net.lang,net.lang.ada Subject: Re: What language do you use for scientific programming? Message-ID: <627@petsd.UUCP> Date: Mon, 26-Aug-85 12:04:50 EDT Article-I.D.: petsd.627 Posted: Mon Aug 26 12:04:50 1985 Date-Received: Tue, 27-Aug-85 06:29:23 EDT References: <909@oddjob.UUCP> <64500002@hpislb.UUCP> Reply-To: joe@petsd.UUCP (Joseph M. Orost) Organization: Perkin-Elmer DSG, Tinton Falls, N.J. Xref: watmath net.lang:1741 net.lang.ada:315 Summary: Correcting Ada issues List-Id: As an Ada implementer, I just want to correct some technical issues in the following article: In article <64500002@hpislb.UUCP> gore@hpisla.UUCP (Jacob Gore) writes: > >Ada is quite similar to Pascal and Modula-2. It does have double-precision >real types. In fact, you can pretty much specify arbitrary precision, as >long as you keep in mind that your program will run faster if there is a >hardware data type in your machine that can support the precision that you >asked for (otherwise, you could be executing lots of simulation code). No simulation code is ever required. Ada allows operations to be performed with more precision than the user requested. Therefore, all operations are done with the next better floating point type in the machine. The "predefined types" of the implementation should correspond with supported types on the machine. In addition, fixed point types are defined in the language to allow representation of fractions on machines that have no floating point hardware. > >Ada follows the philosophy that anything that can be safely put into a >library should not be a burden to the compiler. Following this philosophy, >I/O is not "built into the language" (which usually means that I/O routines >are in the library anyway, but the compiler has to parse calls to those >routines differently from calls to user-written routines). DoD (who set >the requirements for the language) does require provision of library >routines that do minimal I/O, in the manner similar to that of Modula-2, >but slightly more convenient. No, the compiler doesn't parse I/O calls differently than non-I/O calls. > > (4) Ability to pass parameters by name (instead of just their > relative positions within the call) or not to pass them at all. > Many statistical library routines have a dozen or two of > arguments, most of which the user wants to default to their usual > values. In most languages, the best way to do this is to pass > some agreed-upon value, usually 0, which will be replaced with > the default value by the routine. So the call might look like > > CALL FUNFNC (1985, 34, 0,0,0,0,0, -23, 0,0,0,0, 1, 0,0,0,0,0,0) > > In Ada, it would like this: > > FUNNY_FUCNTION (YEAR:=1985, DISTRICT:=34, > PENALTY:=-23, COEFFICIENT:=1); > > The order of the parameters, when passed by name, does not > matter. The correct syntax is: FUNNY_FUNCTION (YEAR => 1985, DISTRICT => 34, PENALTY => -23, COEFFICIENT => 1); > > If you were a customer, which statement would you prefer to use? > Well, if you do want to pass values for most of the parameters, > you might prefer memorizing their positions to spelling out the > name for each of them. But even that is easier to do in Ada: > > FUNNY_FUNCTION (1985, 34, ,,,,, -23, ,,,, 1, ,,,,,); > > And there is no confusion over which parameter gets the default > value, and which actually gets the value of zero! Ada does not allow this! All in all, I agree with you in selecting Ada as your language of choice. Unlike C, however, an efficient Ada program requires a damn-good optimizing compiler. This is good for programmers, because they can concentrate on the algorithm, rather than on an efficient implementation. regards, joe -- ........ ......... Full-Name: Joseph M. Orost . . . UUCP: ihnp4!vax135!petsd!joe . ...... ... ........ ARPA: vax135!petsd!joe@BERKELEY . . Phone: (201) 758-7284 . ......... Location: 40 19'49" N / 74 04'37" W US Mail: MS 313; Perkin-Elmer; 106 Apple St Tinton Falls, NJ 07724