Re: Ada vs Fortran for scientific applications - Programming Languages

"robin" <robin_v@bigpond.com> wrote in message
news:6H9dg.10258$S7.9150@news-server.bigpond.net.au...[color=blue]
> "Dick Hendrickson" <dick.hendrickson@att.net> wrote in message
> news:%P_cg.155733$eR6.26337@bgtnsc04-news.ops.worldnet.att.net...
>[color=green]
>> robin wrote:[color=darkred]
>> > "Dick Hendrickson" <dick.hendrickson@att.net> wrote in message
>> > news:PkHcg.90575$Fs1.7198@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.[/color]
>>[color=darkred]
>> > It can do this only if it is a compiler option.
>> > It is not a feature the language.[/color]
>>
>> There's a ambiguous "it" in those sentences.
>>[/color][/color]
[color=blue][color=green]
>> But, if "it" refers to Fortran, subscript bounds rules
>> ARE a feature of the language.[/color]
>[/color]
[color=blue]
> Subscript bounds checking is not part of the Fortran language.
>[/color]

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

Nasser Abbasi <nma@12000.org> wrote:
[color=blue]
> I just did this simple test, declare an array and go overbound and see if we
> get a run-time error:[/color]
....[color=blue]
> $ g95 f.f90[/color]
....[color=blue]
> $ <------------------- NO runtime ERROR[/color]

This part of the thread has started drifting away from relevance to much
of anything, but that particular sample is just drifting yet further. It
illustrates neither much about subscript bounds rules being part of the
language nor about bounds checking being part of the language, which
were the two topics mentioned earlier in the subthread.

Instead, the example illustrates only that g95 does not have the bounds
check option enabled by default, which is yet a third question (and one
mentioned in more generality earlier).

As with most compilers, g95 does have a bounds check option; it just
isn't enabled by default. Compiling your same example, but asking for
bounds checking, gets it. In particular, compiling and running your
example code on my Mac here with

g95 -fbounds-check clf.f90
./a.out

Gives me:

At line 4 of file clf.f90
Traceback: not available, compile with -ftrace=frame or -ftrace=full
Fortran runtime error: Array element out of bounds: 11 in (1:10), dim=1

which is, in fact, more detailed than the message you showed from gnat.
(Turning on the trace options gets rid of the message about not having
one, but it is trivial and adds nothing else useful for this example.)

--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain

In <1hfv5wb.1x4ab1tbdzk7eN%nospam@see.signature>, on 05/24/2006
at 11:04 PM, [email]nospam@see.sign[/email]ature (Richard Maine) said:
[color=blue]
>As with most compilers, g95 does have a bounds check option; it just
>isn't enabled by default.[/color]

If the language semantics require checking then that is a compiler
bug. In the case of PL/I, the programmer can use (SUBSCRIPTRANGE) and
(NOSUBSCRIPTRANGE) to control array bounds checking, and would be
justifiably upset if the compiler ignored the requests. The same
applies to string bounds checking, with different condition prefixes.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to [email]spamtrap@library.lspace.org[/email]

On Wed, 24 May 2006 23:04:03 -0700, Richard Maine wrote:
[color=blue]
> Nasser Abbasi <nma@12000.org> wrote:
>[color=green]
>> I just did this simple test, declare an array and go overbound and see if we
>> get a run-time error:[/color]
> ...[color=green]
>> $ g95 f.f90[/color]
> ...[color=green]
>> $ <------------------- NO runtime ERROR[/color]
>
> This part of the thread has started drifting away from relevance to much
> of anything, but that particular sample is just drifting yet further. It
> illustrates neither much about subscript bounds rules being part of the
> language nor about bounds checking being part of the language, which
> were the two topics mentioned earlier in the subthread.
>
> Instead, the example illustrates only that g95 does not have the bounds
> check option enabled by default, which is yet a third question (and one
> mentioned in more generality earlier).
>
> As with most compilers, g95 does have a bounds check option; it just
> isn't enabled by default. Compiling your same example, but asking for
> bounds checking, gets it. In particular, compiling and running your
> example code on my Mac here with
>
> g95 -fbounds-check clf.f90
> ./a.out
>
> Gives me:
>
> At line 4 of file clf.f90
> Traceback: not available, compile with -ftrace=frame or -ftrace=full
> Fortran runtime error: Array element out of bounds: 11 in (1:10), dim=1
>
> which is, in fact, more detailed than the message you showed from gnat.
> (Turning on the trace options gets rid of the message about not having
> one, but it is trivial and adds nothing else useful for this example.)[/color]

Bounds checking code is not needed if it can be proved never
to fail. Sometimes the compiler can do that. Sometimes the
programmer can do that, even if the compiler can't.
This is why the *source code* should be able to disable and re-enable
checks with fine granularity. Programmers can comment the code
as to why checks are unnecessary and disable them. This fine-grain
control over checking needs to be standardized across compilers,
otherwise source files become non-portable.
(note: IIRC, the Ariane 5 launch failure was linked to disabling a
range check after careful ****ysis... of Ariane 4 trajectory)

A couple of questions about Fortran:
Are bounds check failures trappable in a standard way so the
program can continue?
Can it be controlled on a finer grain than per compilation?
Do user defined numerical types have restricted bounds too?

The adverse consequences of exceeding bounds can be seen to
outweigh the (usually) modest costs in code size and performance that
even mature code should ship with checks enabled, IMO.
Compilers generally should be shipped with the 'failsafe'
options on by default.
--
Adrian

On 2006-05-25 09:09:59 -0300, "Dr. Adrian Wrigley"
<amtw@linuxchip.demon.co.uk.uk.uk> said:
[color=blue]
> On Wed, 24 May 2006 23:04:03 -0700, Richard Maine wrote:
>[color=green]
>> Nasser Abbasi <nma@12000.org> wrote:
>>[color=darkred]
>>> I just did this simple test, declare an array and go overbound and see if we
>>> get a run-time error:[/color]
>> ...[color=darkred]
>>> $ g95 f.f90[/color]
>> ...[color=darkred]
>>> $ <------------------- NO runtime ERROR[/color]
>>
>> This part of the thread has started drifting away from relevance to much
>> of anything, but that particular sample is just drifting yet further. It
>> illustrates neither much about subscript bounds rules being part of the
>> language nor about bounds checking being part of the language, which
>> were the two topics mentioned earlier in the subthread.
>>
>> Instead, the example illustrates only that g95 does not have the bounds
>> check option enabled by default, which is yet a third question (and one
>> mentioned in more generality earlier).
>>
>> As with most compilers, g95 does have a bounds check option; it just
>> isn't enabled by default. Compiling your same example, but asking for
>> bounds checking, gets it. In particular, compiling and running your
>> example code on my Mac here with
>>
>> g95 -fbounds-check clf.f90
>> ./a.out
>>
>> Gives me:
>>
>> At line 4 of file clf.f90
>> Traceback: not available, compile with -ftrace=frame or -ftrace=full
>> Fortran runtime error: Array element out of bounds: 11 in (1:10), dim=1
>>
>> which is, in fact, more detailed than the message you showed from gnat.
>> (Turning on the trace options gets rid of the message about not having
>> one, but it is trivial and adds nothing else useful for this example.)[/color]
>
> Bounds checking code is not needed if it can be proved never
> to fail. Sometimes the compiler can do that. Sometimes the
> programmer can do that, even if the compiler can't.
> This is why the *source code* should be able to disable and re-enable
> checks with fine granularity. Programmers can comment the code
> as to why checks are unnecessary and disable them. This fine-grain
> control over checking needs to be standardized across compilers,
> otherwise source files become non-portable.
> (note: IIRC, the Ariane 5 launch failure was linked to disabling a
> range check after careful ****ysis... of Ariane 4 trajectory)
>
> A couple of questions about Fortran:
> Are bounds check failures trappable in a standard way so the
> program can continue?
> Can it be controlled on a finer grain than per compilation?[/color]

I am a big fan of subscript checking and undefined variable checking.
I have found that all of the errors that these aids have found have been
in parts of my programs that I believed to be free of such errors
because I had looked hard at them some time before. Either I had
not done a good job of looking or the assumptions underlying the look
had changed.

That seems to be the nature of the beast.

I can avoid (usually!) the trival bugs. I like getting help once the
bug is not trivial. (Maybe that is a definition of trivial.)

Fine grained control would have been of no use, and in fact harmful,
if I had tried to use it. My take is it makes a great checklist feature
that may help get past "desired feature checklists" but is otherwise
not of any real benefit. The check is great but fine grained control
is not.
[color=blue]
> Do user defined numerical types have restricted bounds too?[/color]

That is a Pascal-like feature that I miss in Fortran. So I do my own
checking. Because of my problem domain I have to be proactive in checking
parameter values on entry to new procedures even if the invocation is
from one that has already checked. The buzz word is programming by contract
if I have read the programming fashion of the day rags.

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.
[color=blue]
> The adverse consequences of exceeding bounds can be seen to
> outweigh the (usually) modest costs in code size and performance that
> even mature code should ship with checks enabled, IMO.
> Compilers generally should be shipped with the 'failsafe'
> options on by default.[/color]

Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> wrote:
[color=blue]
> In <1hfv5wb.1x4ab1tbdzk7eN%nospam@see.signature>, on 05/24/2006
> at 11:04 PM, [email]nospam@see.sign[/email]ature (Richard Maine) said:
>[color=green]
> >As with most compilers, g95 does have a bounds check option; it just
> >isn't enabled by default.[/color]
>
> If the language semantics require checking....[/color]

It was mentioned multiple times previously in the thread... oh, but you
are probably posting from the pl1 group, which wasn't in that part of
the thread. Robin apparently added the pl1 group to the list, which I
hadn't noticed until just now. I have no idea whether he also added any
pl1-relevant content or not, as I have him kill-filed.

In any case, no, the Fortran language does not require such checking,
making the clause that I elided from the above sentence moot. The
language rules on bounds are requirements on the programmer - not the
compiler. Pretty much all compilers have a bounds checking option; most
of them have it of by default.

I will refrain from debating the wisdom of this, a comparison of it with
PL1, or indeed, anything in a Fortran vs PL1 subthread that has Robin as
a participant. I won't read his postings, and it would be too hard to
participate usefully in a discussion where I didn't see half the
postings.

--
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 wrote:
[color=blue]
> [...]
> 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.
>[/color]
That's one of the features I miss about the old CDC CYBER architectures.
Their (one's complement, sigh) numeric format supported plus or minus
infinity (e.g., divide a non-zero number by zero) and plus or minus
indefinite (e.g., divide zero by zero, infinity by infinity, or use an
"indefinite" value anywhere in a divide operation). IIRC (it has been a
long time) these values were represented by specific bit patterns in
just the sign and exponent fields. (It also helped that the CYBER
floating point exponent bias was such that the exponent field was zero
for integer values so that integer values representable by 48 or fewer
bits were represented by the same bit patterns in either floating point
or fixed point.

Originally, CYBERs only had an 18-bit address space which was extended
in later models to 21 bits and maybe even to 24 bits in still later
models. The operating system required the high-order bit of any of
those address fields to be zero for user programs.

There was an option for the loader that allowed the exploitation of
these hardware design features to provide automatic checking for
uninitialized values at run time with no run time overhead. The loader
provided a way to specify values to be placed into memory for any
uninitialized program data (I don't remember whether the default was no
value -- e.g., use previous process's leftovers -- or zero). The best
patterns to choose for such initial values were

{plus | minus} {infinity | indefinite}

ORed with

a word with bits 17, 20, and 23 set

ORed with

the load address of the word

Unless one enabled the use of infinity and indefinite values for
arithmetic processing (I never saw that done, but I'm sure some customer
somewhere used it), any use of such values in an arithmetic operation
would be detected by the hardware and stop the program with an error
message containing the value(s) that caused the problem. Further, any
attempt to use such a value as an address would cause the hardware to
stop the program with an error because the high-order bit of the address
field would be set.

Although it didn't provide direct trace back to the source code (because
it was strictly a hardware feature), it was possible to do such trace
backs using load maps because each word contained the address at which
it was originally loaded. Useful, because no such checking was done for
assignments. So, if A were uninitialized in the source code, a sequence
such as:

B = A
C = B
D = C / 4

would halt the program at the divide operation and print out the values,
one of which would contain the address at which A was loaded into
memory. All overhead occurred at initial program load time.

One obvious limitation was that it only worked well for static data and
wasn't all that much help for values allocated on the stack or for
values in FORTRAN blank COMMON or the equivalents in other languages.


I cringe every time I hear some recent grad new hire insist earnestly
that there's no need to initialize anything to zero because that's
always done automatically. And they believe that's true for all
languages -- even for variables allocated on the stack or heap. Worse,
that is in the definitions of a few languages, thus re-inforcing their
belief that it's true for all languages.


Bob Lidral
lidral at alum dot mit dot edu

Dr. Adrian Wrigley wrote:
[color=blue]
> [...]
> The adverse consequences of exceeding bounds can be seen to
> outweigh the (usually) modest costs in code size and performance that
> even mature code should ship with checks enabled, IMO.
> Compilers generally should be shipped with the 'failsafe'
> options on by default.
> --
> Adrian
>[/color]
Certainly the adverse consequences of exceeding bounds can be high -- as
can the adverse consequences of using invalid pointer values. And with
64-bit (or even 32-bit) architectures and paging, code size is not as
much of an issue as it has been for earlier architectures and memory
management technologies.

However, the performance hit of including explicit bounds checking can
be significant -- especially for code with extremely short loops that
are executed a lot of times. It's not just the size of the bounds check
code compared with the size of the rest of the loop. The size of the
bounds check code can increase the size of the loop enough to alter page
usage and bounds checking can also mess up hardware branch prediction
optimization. Granted, there are ways to optimize bounds checking for
loops, including moving the bounds check out of the loop when possible.

Before enabling universal array bounds checking for production code I'd
recommend benchmarking the performance with and without the checks
enabled to determine the real performance cost.


Bob Lidral
lidral at alum dot mit dot edu

"Bob Lidral" <l1dralspamba1t@comcast.net> wrote in message
news:4475DA0F.5030603@comcast.net...[color=blue]
> Gordon Sande wrote:
>[/color]
[color=blue]
> That's one of the features I miss about the old CDC CYBER architectures.
> Their (one's complement, sigh) numeric format supported plus or minus
> infinity (e.g., divide a non-zero number by zero) and plus or minus
> indefinite (e.g., divide zero by zero, infinity by infinity, or use an
> "indefinite" value anywhere in a divide operation).[/color]

hi,

fyi, Matlab supports NAN's, and it has Inf and -Inf (infinities)
[color=blue][color=green]
>> a=1/0;[/color][/color]
Warning: Divide by zero.[color=blue][color=green]
>> a[/color][/color]
a =
Inf
[color=blue][color=green]
>> a-Inf[/color][/color]
ans =
NaN
[color=blue][color=green]
>> 1-Inf[/color][/color]
ans =
-Inf

Mathematica also:

In[12]:= 1./0;
(warning displayed like in Matlab)

Out[13]= ComplexInfinity


Nasser