Ada vs Fortran for scientific applications
in [Fortran]
|
From: adaworks on 9 Jul 2006 16:52 "Gordon Sande" <g.sande(a)worldnet.att.net> wrote in message news:2006052509454116807-gsande(a)worldnetattnet... > > How many Ada systems can match the undefined variable checking of the > old WatFor or the current Salford CheckMate or the Lahey/Fujitsu > global checking? It seems to be a thing associated with places that > run student cafteria computing on mainframes. Not much used anymore. > There was a similar student checkout PL/I from Cornell if I recall > correctly. > The default for Ada is to do thorough range checking on all numeric types. A designer may suppress that default, selectively, if it is deemed unnecessary. Ada allows the explicity declaration of range constraints, bit mapping, and other low-level features. Examples: type My_Number is range 3..56; -- sets the upper and lower bounds -- on an integer type type My_Float is digits 7 range -200.0 .. 500.0; -- sets the number of digits -- and the range for this type These are just two examples. The same thing can be done for decimal types, modular types, fixed-point types, etc. Ada also uses the name-equivalence, rather than the structural equivalence approach to checking (at compile time). Therefore, type N1 is range 0..100; type N2 is range 0..100; with X : N1; -- X is of type N1 Y : N2; -- Y is of type N2; will reject, X := Y +1; Y is incompatible, by name, with X; Some languages will accept the above statement because the two values have types that are structurally equivalent. One of the principle features of Ada is the rigor of its checking both at compile-time and run-time. This includes indices, ordinary numeric types, subscripts, etc. Richard Riehle
From: James Giles on 9 Jul 2006 17:36 adaworks(a)sbcglobal.net wrote: > "Gordon Sande" <g.sande(a)worldnet.att.net> wrote in message > news:2006052509454116807-gsande(a)worldnetattnet... >> >> How many Ada systems can match the undefined variable checking of the >> old WatFor or the current Salford CheckMate or the Lahey/Fujitsu >> global checking? It seems to be a thing associated with places that >> run student cafteria computing on mainframes. Not much used anymore. >> There was a similar student checkout PL/I from Cornell if I recall >> correctly. >> > The default for Ada is to do thorough range checking on all numeric > types. A designer may suppress that default, selectively, if it is > deemed unnecessary. > [... lots of Ada features ...] All the stuff I elided is interesting. Many of the features are even good things for languages to have. None of them were checks for undefined variables. Given the Ada program fragment: COUNT, SUM : INTEGER; [... lots of code ...] [... some paths through which assign to SUM ...] [... and some don't ...] COUNT := SUM+1; -- is SUM defined here or not? In most Ada implementations, as for most other languages, all the bit patterns in the representation of an INTEGER data type are valid integer values. There is no bit pattern representing NOI (Not An Integer) corresponding to the IEEE float idea of a NAN. Determining whether a variable is defined or not is a complex problem. It's made worse by the fact that the user can make the error message go away (though not usually the problem) by initializing the variable in the declaration. -- J. Giles "I conclude that there are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies." -- C. A. R. Hoare
From: Brooks Moses on 9 Jul 2006 17:33 adaworks(a)sbcglobal.net wrote: > Ada also uses the name-equivalence, rather than the structural equivalence > approach to checking (at compile time). Therefore, > > type N1 is range 0..100; > type N2 is range 0..100; > > with > > X : N1; -- X is of type N1 > Y : N2; -- Y is of type N2; > > will reject, > > X := Y +1; Y is incompatible, by name, with X; As a curiousity question, how would this work for cases such as, say, a finite-volume grid where I have one range for the cells, and another range for the faces between the cells, and want to do soemthing like this: type ncells is range 1..100; type nfaces is range 0..100; cell : ncells; leftface : nfaces; rightface : nfaces; leftface = cell - 1; rightface = cell; According your explanation those last two commands, while making logical sense, would throw a type-mismatch error. How easy is that to "fix"? - Brooks -- The "bmoses-nospam" address is valid; no unmunging needed.
From: Martin Dowie on 9 Jul 2006 18:29 James Giles wrote: > All the stuff I elided is interesting. Many of the features are even > good things for languages to have. None of them were checks for > undefined variables. > > Given the Ada program fragment: > > COUNT, SUM : INTEGER; > > [... lots of code ...] > [... some paths through which assign to SUM ...] > [... and some don't ...] > > COUNT := SUM+1; -- is SUM defined here or not? > > In most Ada implementations, as for most other languages, all > the bit patterns in the representation of an INTEGER data type > are valid integer values. That's not entirely true, the standard states Integer must include the range ?2**15+1 .. +2**15?1 - thus (usually) leaving -2**15 as a possible 'default uninitialized' value. Implementations /may/ do something else (e.g. on 32-bit architectures providing 'Integer' with the range -2**31+1 .. 2**31-1) and this should be stated in their own documentation (as per Annex M of the Ada language standard). Cheers -- Martin
From: James Giles on 9 Jul 2006 19:07
Martin Dowie wrote: > James Giles wrote: .... >> In most Ada implementations, as for most other languages, all >> the bit patterns in the representation of an INTEGER data type >> are valid integer values. > > That's not entirely true, the standard states Integer must include the > range ?2**15+1 .. +2**15?1 - thus (usually) leaving -2**15 as a > possible 'default uninitialized' value. Well I allowed for that possibility. I made no absolute assertion. I said "most Ada implementations". In fact, most language definitions *allow* implementations to implement integers with a lot of flexibility. Most actual implementations use all the bit patterns their underlying hardware allows and *don't* use any of them for NOI (Not An Integer). And, let's not forget character data types (does your actual implementation have a value that means NOC - Not A Character?). What about booleans? Ada also has fixed point types, enumerations, records, etc. Does your actual implementation catch uses of undefined variables for all those? Indeed, does it even use NANs from the floating point hardware to detect uninitialized REALs? It's true: nearly all languages permit implementations to internally represent data with additional memory for the purpose of detecting and reporting uses of undefined variables (and for other reasons - like the value of a variable that was defined, but the expression involved an unhandled exception). In formal semantics, the idea is called a lifted domain. Applying it in software is expensive at run-time. Now, I've always liked the idea of using the anomalous value in two's complement integers (sign bit set, all others clear) as NOI. I don't think it's a likely implementation strategy unless it was treated that way in hardware. -- J. Giles "I conclude that there are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies." -- C. A. R. Hoare |