Merits of fortran

5 views
Skip to first unread message

Richard Harter

unread,
Mar 10, 2007, 10:13:21 AM3/10/07
to

This is a general question for the group. Fortran is widely perceived
as being a superior language for numeric and scientific programming.
What are the features and aspects that make it so. Here are some
thoughts in no particular order:

* The existence of a large body of important legacy code
* More efficient code because it doesn't have aliasing problems
* Mathematical routines built into the language
* Good support for complex arithmetic
* Sensible handling of multi-dimensional data (as compared to C)


max

unread,
Mar 10, 2007, 10:34:59 AM3/10/07
to

"Richard Harter" <c...@tiac.net> wrote in message
news:45f2c8f9....@news.sbtc.net...
With the exception of legacy code, and probably arrays, I understood C99 to
have caught up with, if not overtaken, Fortran. A C++ programmer (OK,
different language) assures me that C++ now has proper arrays, not pointert
o pointer structures. I'm not enough of a lawyer to be penetrate the pice of
the standard he referred me to.

Legacy code is, in part, dealt with by having a 'legacy' Fortran compiler
that can produce linkable code - part of the approach used by Watcom, Absoft
and (to a lesser extent) Intel & Salford, plus the Unix vendors.

It still has the advantages of a perception of efficiency, and, importantly,
that Fprtran code for algorithms does seem (usually) easier to follow than
equivalent languages - especially with the advent of Fortran 90.


Beliavsky

unread,
Mar 10, 2007, 11:04:36 AM3/10/07
to

An answer to your question is in part a matter of opinion -- here is
mine.

Fortran 77:
A "safe" DO loop that prohibits changing the loop variable within the
loop.

Arrays with lower bounds of 1 by default (and other bounds if
desired).

The existence of both functions and subroutines, permitting (but not
requiring) functions to be used in a restricted way similar to
mathematical functions.

Generic intrinsic functions that work for both real and double
precision variables.

Not requiring semicolons to terminate statements, which prevents some
hard-to-find bugs, especially within IF constructs. (Not specific to
scientific programming.)

Fortran 90 and 95:
Operations on whole arrays and array sections using a variety of
intrinsic functions.

Charles Russell

unread,
Mar 10, 2007, 11:17:44 AM3/10/07
to
Richard Harter wrote:
> This is a general question for the group. Fortran is widely perceived
> as being a superior language for numeric and scientific programming.
> What are the features and aspects that make it so.

Array bounds check is normally available as a simple compiler option.

Louis Krupp

unread,
Mar 10, 2007, 11:50:54 AM3/10/07
to

C has true multi-dimensional arrays ("int a[3][5]") as well as the
"array of pointer" thing ("int *a[3]"). C does not have all the array
intrinsics of Fortran 90/95, and without the "assumed shape" concept,
it's a lot easier to write buggy code in C.

Louis

Richard Harter

unread,
Mar 10, 2007, 12:18:06 PM3/10/07
to

All too true. I didn't mean to say that C doesn't have
multi-dimensional arrays, merely that that the treatment isn't, ah,
adequate.

Gib Bogle

unread,
Mar 10, 2007, 2:24:31 PM3/10/07
to
max wrote:
> I'm not enough of a lawyer to be penetrate the pice of
> the standard he referred me to.

Well, I'm not enough of a lawyer to be penetrate the pice of this sentence.

Richard Harter

unread,
Mar 10, 2007, 4:53:42 PM3/10/07
to
On 10 Mar 2007 08:04:36 -0800, "Beliavsky" <beli...@aol.com> wrote:

>On Mar 10, 10:13 am, c...@tiac.net (Richard Harter) wrote:
>> This is a general question for the group. Fortran is widely perceived
>> as being a superior language for numeric and scientific programming.
>> What are the features and aspects that make it so. Here are some
>> thoughts in no particular order:
>>
>> * The existence of a large body of important legacy code
>> * More efficient code because it doesn't have aliasing problems
>> * Mathematical routines built into the language
>> * Good support for complex arithmetic
>> * Sensible handling of multi-dimensional data (as compared to C)
>
>An answer to your question is in part a matter of opinion -- here is
>mine.

And thank you very much. The last time I used fortran was about 25
years ago. Fortran today is definitely not your grandfather's fortran.
My current perspective is that of a language designer - what is it that
makes today's fortran special.

Here are a few comments on your thoughts.

>
>Fortran 77:
>A "safe" DO loop that prohibits changing the loop variable within the
>loop.

This is apparently minor but it may be more important than it seems at
first sight.

>
>Arrays with lower bounds of 1 by default (and other bounds if
>desired).

Zero based arrays treat array indices as offsets; one based arrays treat
array indices as position ordinals. There are arguments both ways;
mostly it's a matter of where the magic '1' goes in the code.

>
>The existence of both functions and subroutines, permitting (but not
>requiring) functions to be used in a restricted way similar to
>mathematical functions.

That's not particular to fortran. Languages that only have functions
sneak subroutines in the back door with functions that don't return
anything.

>
>Generic intrinsic functions that work for both real and double
>precision variables.

This one strikes as being very important. It's a common tactic in many
languages to have a core language and push the utilities off into
libraries. The tactic is convenient for implementors but it creates
usage problems. The key words here are "generic" and "intrinsic".


>
>Not requiring semicolons to terminate statements, which prevents some
>hard-to-find bugs, especially within IF constructs. (Not specific to
>scientific programming.)

I agree; others may not. Using semicolons to separate or terminate
statements always struck me as a hack for the convenience of compiler
writers.



>
>Fortran 90 and 95:
>Operations on whole arrays and array sections using a variety of
>intrinsic functions.

Very important in my opinion - few languages have decent support for
multi-dimensional arrays.

Sebastian Hanigk

unread,
Mar 10, 2007, 5:27:18 PM3/10/07
to
c...@tiac.net (Richard Harter) writes:

>>Arrays with lower bounds of 1 by default (and other bounds if
>>desired).
>
> Zero based arrays treat array indices as offsets; one based arrays treat
> array indices as position ordinals. There are arguments both ways;
> mostly it's a matter of where the magic '1' goes in the code.

Don't forget that arbitrary values for start and end indices are a
blessing, if your problem is formulated in such a way; a classic example
would be ghost cells in a numerical simulation.

In the end, working with arrays in C is always working directly with the
memory addressing scheme, while Fortran arrays shift the addressing
burden onto the compiler. I wouldn't be surprised if the number of "off
by one" errors done programming in C versus programming in Fortran is
significantly larger.


Sebastian

glen herrmannsfeldt

unread,
Mar 10, 2007, 7:01:59 PM3/10/07
to
Louis Krupp wrote:
> Richard Harter wrote:

>> This is a general question for the group. Fortran is widely perceived
>> as being a superior language for numeric and scientific programming.
>> What are the features and aspects that make it so. Here are some
>> thoughts in no particular order:

(snip)

>> * Sensible handling of multi-dimensional data (as compared to C)

> C has true multi-dimensional arrays ("int a[3][5]") as well as the
> "array of pointer" thing ("int *a[3]"). C does not have all the array
> intrinsics of Fortran 90/95, and without the "assumed shape" concept,
> it's a lot easier to write buggy code in C.

While some people don't count that as multidimensional, I personally
believe that it does. Until C99, though, the dimensions had to be
compile time constants. Even Fortran 66 allows one to use variables
to dimension dummy arrays of called routines, but C89 and earlier
do not. I believe this was finally fixed in C99. (I haven't
tried it yet.)

Otherwise the called routine can calculate the offset from the
array origin, which many Fortran 66 programs did, also, or use
the array of pointers method.

In the 16 bit x86 days (DOS and OS/2) I used the array of pointers
to reference fairly large arrays as long as each column was less than
64K bytes. It wasn't so fast, but it was likely faster than huge
model.

-- glen

Brooks Moses

unread,
Mar 10, 2007, 7:47:09 PM3/10/07
to
Richard Harter wrote:
> On 10 Mar 2007 08:04:36 -0800, "Beliavsky" <beli...@aol.com> wrote:
>> The existence of both functions and subroutines, permitting (but not
>> requiring) functions to be used in a restricted way similar to
>> mathematical functions.
>
> That's not particular to fortran. Languages that only have functions
> sneak subroutines in the back door with functions that don't return
> anything.

Right, but doing that requires allowing functions to modify their
arguments or otherwise have side effects (such as modifying pointer
targets, as C functions do).

Admittedly, Fortran does allow this in normal functions, but it also
allows PURE functions, which don't have side effects. I think that
those, and the whole INTENT declaration mechanism for procedure
arguments in general, are definitely an advantage for Fortran.

Which reminds me of another thing: Fortran's pointer handling has some
very definite advantages, in requiring that pointer targets be declared
as TARGET so that the compiler can assume when optimizing that most
things are not pointer targets, and in letting pointers point to array
sections and such rather than just to single memory locations.

- Brooks

--
The "bmoses-nospam" address is valid; no unmunging needed.

James Giles

unread,
Mar 10, 2007, 9:03:23 PM3/10/07
to
Brooks Moses wrote:
> Richard Harter wrote:
...

>> That's not particular to fortran. Languages that only have functions
>> sneak subroutines in the back door with functions that don't return
>> anything.
>
> Right, but doing that requires allowing functions to modify their
> arguments or otherwise have side effects (such as modifying pointer
> targets, as C functions do).

On the other hand, there are very few things you can do with
truly pure functions. I have one that's perhaps a few dozen
lines long that's truly pure. But that's unusually long.

Most functions at the very least might have such side-effects as
numerical exceptions. The lack of a way to report errors is a
severe weakness of pure functions. The only way to achieve
it is to use "lifted domains". That is, all the return types of
your functions must have values that the rest of the program
regards as error conditions - and the rest of the program
propagates those accordingly. Most Fortran data types aren't
equipped with such and few programmers choose to create
their own types with that property. The NaNs of IEEE floats
could be used as such. How many program's functions only
return floats?

Fortran's definition of PURE differs from the rest of the industry
too. It fails to meet the first part of the wikipedia definition:
http://en.wikipedia.org/wiki/Pure_function
In fact, in Fortran a PURE function may have no arguments
at all and exist to report some current property of one or more
MODULE or COMMON variables. The value of such functions
changes every time those MODULE or COMMON contents do.

Allowing functions to have side-effects is, as a practical matter,
almost unavoidable in a language that's not purely functional
in the first place. It's best to try to simplify the language by
eliminating unnecessary differences between functions and
subroutines. A function should be regarded as a subroutine
whose reference occurs in an expression (and therefore it
has a value). No other distinctions are really useful.

--
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


Dan Nagle

unread,
Mar 10, 2007, 9:47:48 PM3/10/07
to
Hello,

James Giles wrote:

<snip>

> Most functions at the very least might have such side-effects as
> numerical exceptions. The lack of a way to report errors is a
> severe weakness of pure functions.

That's one motivation for the "impure elementals" in f08.

<snip the rest>

--
Cheers!

Dan Nagle
Purple Sage Computing Solutions, Inc.

David Rowell

unread,
Mar 11, 2007, 8:58:44 AM3/11/07
to
exponentiation to a simple integer power

David Flower

unread,
Mar 11, 2007, 3:36:47 PM3/11/07
to

* The use of newline as the delimiter between statements; much the
most sensible.

* A straightforward CHARACTER variable of any length

Dave Flower

Greg Lindahl

unread,
Mar 12, 2007, 12:32:04 AM3/12/07
to
In article <1173641807....@p10g2000cwp.googlegroups.com>,
David Flower <DavJF...@AOL.COM> wrote:

>* The use of newline as the delimiter between statements; much the
>most sensible.

... one would hope that it's easy to see that this isn't a significant
merit of Fortran.

-- g

James Giles

unread,
Mar 12, 2007, 1:06:19 AM3/12/07
to

Experiments (plural) in the 70's indicated that programmers
tend to regard the end of a line as synonymous with the end
of a statement. Productivity was improved by requiring
explicit continuation marks if the intent was different than
that usual situation.

Whether it counts as *significant* or not, it does count as
one of Fortran's merits.

glen herrmannsfeldt

unread,
Mar 12, 2007, 5:17:37 AM3/12/07
to
James Giles wrote:
(snip)

> Experiments (plural) in the 70's indicated that programmers
> tend to regard the end of a line as synonymous with the end
> of a statement. Productivity was improved by requiring
> explicit continuation marks if the intent was different than
> that usual situation.

Having used languages that have statement end markers,
those that didn't, and even some in between, it doesn't
take me long to adapt.

I believe the original IBM S/360 JCL interpreter required continuation
marks (in column 72), but it was later changed to work without them.
If the operand field ends in a comma, it recognizes a continuation
without an explicit continuation mark, though no statement end mark
is required or possible. In JCL, like S/360 Assembler (which does
require continuation marks) uses blanks to separate the name,
operation, operand, and comment fields. If the operand field ends
in a comma it can still be followed by comments, with operands
continued on the next line.

R (and S), and Mathematica also allow continuation of statements
that end with an operator, or with an incomplete parenthesized
expression. This has some strange results for R's IF/THEN/ELSE
structure where the ELSE can't begin on its own line, as there
would be no indication of the continuation.

Otherwise, I would say the biggest problem is the null statement
that C, Java, and PL/I have, which can't be recognized if the line
terminator is missing. Adding an explicit null statement to those
languages might reduce the problems of missing line end characters.

> Whether it counts as *significant* or not, it does count as
> one of Fortran's merits.

-- glen

Gordon Sande

unread,
Mar 12, 2007, 9:01:31 AM3/12/07
to

The question of whether the semicolon is a terminator or a separator
is one of those things that makes for annoying syntax errors.

In practice the question is whether there has to be a semicolon
before the end in languages like Algol or Pascal where end is used
as a statement grouping "bracket". It confuses beginners but most
folks sort it out by the time they make the same mistake several
times.

The use of the line end as a statement end is more an issue of whether
the continuation mechanism makes sense. Fortran free format is very
good and a major improvement over fixed format. You have to ask for
continuation and it is clear when it is being asked for. Having a
trailing operator act as continuation is slick but requires some
special casing if it is possible for a statement to end with an
operator as the DATA statement does.

Beliavsky

unread,
Mar 12, 2007, 10:10:41 AM3/12/07
to
On Mar 10, 11:13 am, c...@tiac.net (Richard Harter) wrote:
> This is a general question for the group. Fortran is widely perceived
> as being a superior language for numeric and scientific programming.
> What are the features and aspects that make it so.

I should have mentioned the KIND mechanism of Fortran 90, designed to
improve portability of numerical codes across platforms. Fortran 2003
extends this by allowing "parameterized derived types".

Michael Prager

unread,
Mar 12, 2007, 10:52:05 AM3/12/07
to
c...@tiac.net (Richard Harter) wrote:

> >Not requiring semicolons to terminate statements, which prevents some
> >hard-to-find bugs, especially within IF constructs. (Not specific to
> >scientific programming.)
>
> I agree; others may not. Using semicolons to separate or terminate
> statements always struck me as a hack for the convenience of compiler
> writers.

Another purely visual issue is Fortran's use of enclosing block
statements (e.g., DO, END DO). I program in a couple of
languages that use curly braces to group statements, and I find
that usage more error prone than Fortran (or for that matter,
than Python, in which indentation itself marks blocks).

--
Mike Prager, NOAA, Beaufort, NC
Address spam-trapped; remove color to reply.
* Opinions expressed are personal and not represented otherwise.
* Any use of tradenames does not constitute a NOAA endorsement.

Pierre Asselin

unread,
Mar 12, 2007, 12:30:27 PM3/12/07
to
Richard Harter <c...@tiac.net> wrote:

> This is a general question for the group. Fortran is widely perceived
> as being a superior language for numeric and scientific programming.
> What are the features and aspects that make it so.

I'd say better optimization.

> Here are some thoughts in no particular order:

I permuted them, since the order was arbitrary :)

> * The existence of a large body of important legacy code

> * Mathematical routines built into the language

Yes, there is some of that.

> * More efficient code because it doesn't have aliasing problems

> * Good support for complex arithmetic
> * Sensible handling of multi-dimensional data (as compared to C)

Since you compare with C, these three have been addressed in C99
(about time!). Restrict- qualified pointers, complex numbers and
variable length arrays.

From my own fragmentary experience, the restrict pointers make
a difference. I don't know if they are enough to catch up
with Fortran.

--
pa at panix dot com

James Giles

unread,
Mar 12, 2007, 1:35:59 PM3/12/07
to
glen herrmannsfeldt wrote:
...

> Otherwise, I would say the biggest problem is the null statement
> that C, Java, and PL/I have, which can't be recognized if the line
> terminator is missing. Adding an explicit null statement to those
> languages might reduce the problems of missing line end characters.

I would recommend instead eliminating the ability to have
any control construct from having a null statement as its
body. Allow an empty block for that purpose, but not a
null statement. That eliminates the problem.

Alinabi

unread,
Mar 12, 2007, 1:41:01 PM3/12/07
to

The KIND mechanism of Fortran has seen better incarnations in other
languages (e.g. Ada), so it is not a merit of Fortran, unless you only
compare it to C.

Beliavsky

unread,
Mar 12, 2007, 2:11:15 PM3/12/07
to
On Mar 12, 1:41 pm, "Alinabi" <alexander.the.aver...@gmail.com> wrote:

<snip>

> > I should have mentioned the KIND mechanism of Fortran 90, designed to
> > improve portability of numerical codes across platforms. Fortran 2003
> > extends this by allowing "parameterized derived types".
>
> The KIND mechanism of Fortran has seen better incarnations in other
> languages (e.g. Ada), so it is not a merit of Fortran, unless you only
> compare it to C.

I am unfamiliar with Ada -- how is its incarnation better?

Alinabi

unread,
Mar 12, 2007, 3:40:20 PM3/12/07
to

Ada's version of SELECTED_REAL_KIND(P,R) is:

type MyRealType is digits P range 10**-R..10**R

which defines a floating point type with P digits and values between
10**-R..10**R. However, the range is enforced by the compiler, even if
the underlying representation allows values outside this range. For
example, if you do this

type Real1 is digits 7 range 0..10**3;
A : Real1;
A := 3.0;

the compiler will generate an error. Also, by default range
constraints are checked at runtime. For performance sensitive
procedures you can turn these runtime checks off with a compiler
pragma:

procedure Must_Be_Fast(X: in Real1)
pragma Suppress(Range_Check);

In fact pragma Suppress has even better granularity and can be applied
only to a specified type or object, if that is what you need. So,

type Real1 is digits 7 range 0..10**3;
pragma Suppress(Range_Check, Real1);

would suppress range checks for all objects of type Real1, while still
performing the checks for any other type.

Now, if you think that this is not a significant improvement over what
Fortran has, at least in the context of numerical computation, that is
fine by me. But I don't see how one could argue that Fortran's KIND
mechanism is better.

Colin Watters

unread,
Mar 12, 2007, 4:25:18 PM3/12/07
to

> For example, if you do this
>
> type Real1 is digits 7 range 0..10**3;
> A : Real1;
> A := 3.0;
>
> the compiler will generate an error.

...I may be missing something blindingly obvious... Why is this an error?
Seems to me that 3 is between 0 and 1000 and so should be ok.

--
Qolin

Email: my qname at domain
Domain: qomputing dot demon dot co dot uk
"Alinabi" <alexander....@gmail.com> wrote in message
news:1173728420....@30g2000cwc.googlegroups.com...

Gary Scott

unread,
Mar 12, 2007, 4:32:40 PM3/12/07
to
Alinabi wrote:

> On Mar 12, 2:11 pm, "Beliavsky" <beliav...@aol.com> wrote:
>
>>On Mar 12, 1:41 pm, "Alinabi" <alexander.the.aver...@gmail.com> wrote:
>>
>><snip>
>>
>>>>I should have mentioned the KIND mechanism of Fortran 90, designed to
>>>>improve portability of numerical codes across platforms. Fortran 2003
>>>>extends this by allowing "parameterized derived types".
>>
>>>The KIND mechanism of Fortran has seen better incarnations in other
>>>languages (e.g. Ada), so it is not a merit of Fortran, unless you only
>>>compare it to C.
>>
>>I am unfamiliar with Ada -- how is its incarnation better?
>
>
> Ada's version of SELECTED_REAL_KIND(P,R) is:
>
> type MyRealType is digits P range 10**-R..10**R
>
> which defines a floating point type with P digits and values between
> 10**-R..10**R. However, the range is enforced by the compiler, even if
> the underlying representation allows values outside this range. For
> example, if you do this

Something I like, but something I would like to associate with a bit
string data type that can be fully definable in terms of bit encoding
scheme, msb/lsb, scale factors, signed/unsigned, hex float, IEEE754,
zoned, number of bits in mantissa, etc. If you go down this road, then
build a full-fledged capability, not a bandaid that only works on
"native" types. Let the compiler figure out when I've defined something
compatible with native types and give me optimum native performance, or
handle it in software if I haven't. I would be defining types the way
they need to be defined to match some particular hardware I'm trying to
emulate or to map to some communication device in a more natural way,
rather than trying to wedge it into a foreign ("native") data type.

>
> type Real1 is digits 7 range 0..10**3;
> A : Real1;
> A := 3.0;
>
> the compiler will generate an error. Also, by default range
> constraints are checked at runtime. For performance sensitive
> procedures you can turn these runtime checks off with a compiler
> pragma:
>
> procedure Must_Be_Fast(X: in Real1)
> pragma Suppress(Range_Check);
>
> In fact pragma Suppress has even better granularity and can be applied
> only to a specified type or object, if that is what you need. So,
>
> type Real1 is digits 7 range 0..10**3;
> pragma Suppress(Range_Check, Real1);
>
> would suppress range checks for all objects of type Real1, while still
> performing the checks for any other type.
>
> Now, if you think that this is not a significant improvement over what
> Fortran has, at least in the context of numerical computation, that is
> fine by me. But I don't see how one could argue that Fortran's KIND
> mechanism is better.
>


--

Gary Scott
mailto:garylscott@sbcglobal dot net

Fortran Library: http://www.fortranlib.com

Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html

If you want to do the impossible, don't hire an expert because he knows
it can't be done.

-- Henry Ford

Greg Lindahl

unread,
Mar 12, 2007, 4:45:22 PM3/12/07
to
In article <1173721261.1...@s48g2000cws.googlegroups.com>,
Alinabi <alexander....@gmail.com> wrote:

>The KIND mechanism of Fortran has seen better incarnations in other
>languages (e.g. Ada), so it is not a merit of Fortran, unless you only
>compare it to C.

Even C has a way of doing it (configure scripts); folks here may not
like it, but it exists & is commonly used.

Much PL/I code was rendered unportable by the use of a good version of
this feature; programmers asked for >32 bit values for no particular
reason, so it became tedious to attempt to port such code to 32-bit
machines ("do we have a test that proves we can shrink this variable?")

-- g

Craig Powers

unread,
Mar 12, 2007, 5:42:58 PM3/12/07
to
max wrote:
> A C++ programmer (OK,
> different language) assures me that C++ now has proper arrays, not pointert
> o pointer structures.

I've been a C++ programmer in the past (although I'm only working with
Fortran right now), and I disagree with that statement. C++ has
improved support for multidimensional data relative to C, but still
nothing that's as natural to use as Fortran arrays -- and what it does
have, it has via standardized library templates (or third-party
templates) rather than native language constructs.

There are a lot of things that I like about C++, but its handling of
array data is not one of them.

Gary Scott

unread,
Mar 12, 2007, 5:44:32 PM3/12/07
to
Greg Lindahl wrote:

one of the reasons why a it should be done in software, so that it can
handle such portability issues maximally (if not perfectly).

> -- g

Gary Scott

unread,
Mar 12, 2007, 5:46:32 PM3/12/07
to
Craig Powers wrote:

But why is that? It seems like such an easy and obvious feature. There
must be some resistance to it?

Alinabi

unread,
Mar 12, 2007, 5:55:03 PM3/12/07
to
On Mar 12, 4:25 pm, "Colin Watters"

<qolin.see_signat...@nowhere.co.uk> wrote:
> > For example, if you do this
>
> > type Real1 is digits 7 range 0..10**3;
> > A : Real1;
> > A := 3.0;
>
> > the compiler will generate an error.
>
> ...I may be missing something blindingly obvious... Why is this an error?
> Seems to me that 3 is between 0 and 1000 and so should be ok.
>
> --
> Qolin
>
> Email: my qname at domain
> Domain: qomputing dot demon dot co dot uk"Alinabi" <alexander.the.aver...@gmail.com> wrote in message

Sorry. I meant to say A:= -3.0

ejk...@gmail.com

unread,
Mar 12, 2007, 6:21:14 PM3/12/07
to
On Mar 12, 2:46 pm, Gary Scott <garylsc...@sbcglobal.net> wrote:

> >> A C++ programmer (OK,
> >> different language) assures me that C++ now has proper arrays, not
> >> pointert
> >> o pointer structures.
>
> > I've been a C++ programmer in the past (although I'm only working with
> > Fortran right now), and I disagree with that statement. C++ has
> > improved support for multidimensional data relative to C, but still
> > nothing that's as natural to use as Fortran arrays -- and what it does
> > have, it has via standardized library templates (or third-party
> > templates) rather than native language constructs.
>
> > There are a lot of things that I like about C++, but its handling of
> > array data is not one of them.
>
> But why is that? It seems like such an easy and obvious feature. There
> must be some resistance to it?

The problem with C++ is that the base language, like C90, does *not*
support arrays per se - one can only manipulate a pointer to a block
of
storage. The C++ standard library attempts to emulate 1-d arrays
using templated
structures, but does so with two incompatible constructs: vector and
valarray. The proposed 2003 C++ library adds two more: tuple and
array.

Then there are many other libraries that define array- and matrix-like
structures: lapack++, Matrix Template Library, Blitz++, etc., that are
not
part of the C++ standard but which have been attempted by various
authors.
They range from abandoned to actively developed.

Insofar as arrays and vectors are by far the most commonly used data
structures in scientific programming, the C++ situation is simply
disastrous
from the point of view of code re-use.

Two C++ codes that use different array constructs are simply
incompatible, and
getting the two to interoperate means a complete rewrite of one of
them.
There's no way to know which matrix/vector library will survive, so
one cannot
know whether one's scientific C++ code will be rendered unusable in a
few years'
time.

--Eric

Gary Scott

unread,
Mar 12, 2007, 6:34:39 PM3/12/07
to
ejk...@gmail.com wrote:

ick. how can anyone even live without good arrays?!?

>
> --Eric

James Giles

unread,
Mar 12, 2007, 8:59:43 PM3/12/07
to
Gary Scott wrote:
...

> Something I like, but something I would like to associate with a bit
> string data type that can be fully definable in terms of bit encoding
> scheme, msb/lsb, scale factors, signed/unsigned, hex float, IEEE754,
> zoned, number of bits in mantissa, etc. If you go down this road,
> then build a full-fledged capability, not a bandaid that only works on
> "native" types. [...]

How are any of these characteristics associated with a "bit string"?
They seem to have no similarity to, say, character string (whose
elements are limited to bits?).

It seems that the existing derived type mechanism augmented to
allow components that are declared as bit-resolution objects would
suffice. Each such type would then have its principal operations
defined according to the characteristics you desire. Again, nothing
to do with "strings", bit or otherwise.

Maybe you want the compiler to be able to create such derived types
for you. That's way too complex and esoteric for a general purpose
language.

Dan Nagle

unread,
Mar 12, 2007, 9:17:06 PM3/12/07
to
Hello,

Gary Scott wrote:

<snip requoted>

> ick. how can anyone even live without good arrays?!?

How 'bout: With a Really Neat (tm) Class Structure? ;-)

Diamonds are Forever.

Gary Scott

unread,
Mar 12, 2007, 9:19:19 PM3/12/07
to
James Giles wrote:
> Gary Scott wrote:
> ...
>
>>Something I like, but something I would like to associate with a bit
>>string data type that can be fully definable in terms of bit encoding
>>scheme, msb/lsb, scale factors, signed/unsigned, hex float, IEEE754,
>>zoned, number of bits in mantissa, etc. If you go down this road,
>>then build a full-fledged capability, not a bandaid that only works on
>>"native" types. [...]
>
>
> How are any of these characteristics associated with a "bit string"?
> They seem to have no similarity to, say, character string (whose
> elements are limited to bits?).
>
> It seems that the existing derived type mechanism augmented to
> allow components that are declared as bit-resolution objects would
> suffice. Each such type would then have its principal operations
> defined according to the characteristics you desire. Again, nothing
> to do with "strings", bit or otherwise.
>
> Maybe you want the compiler to be able to create such derived types
> for you. That's way too complex and esoteric for a general purpose
> language.
>
They CAN be related in that I want to be able to define the number of
bits that constitute a type that I am defining to be substring of a bit
string. This reduces impact to existing, native language features
(native types, kind system).

James Giles

unread,
Mar 12, 2007, 9:54:55 PM3/12/07
to
Gary Scott wrote:
> James Giles wrote:
...

>> It seems that the existing derived type mechanism augmented to
>> allow components that are declared as bit-resolution objects would
>> suffice. Each such type would then have its principal operations
>> defined according to the characteristics you desire. Again, nothing
>> to do with "strings", bit or otherwise.
...

> They CAN be related in that I want to be able to define the number of
> bits that constitute a type that I am defining to be substring of a
> bit string. This reduces impact to existing, native language features
> (native types, kind system).

Why couldn't it be a slice of an array or a component of a derived
type? Why "string" particularly? Especially since Fortran doesn't
have such a feature and it would, in itself, constitute a big impact
on the language. Even with the new BIT type: you can create arrays
of it; you can make it a type component, but you can't make strings
of it. The string mechanism of Fortran is bound very tightly to the
CHARACTER data type. (I think it shouldn't be, but that's another
thread.)

Gary Scott

unread,
Mar 12, 2007, 10:19:42 PM3/12/07
to
James Giles wrote:

> Gary Scott wrote:
>
>>James Giles wrote:
>
> ...
>
>>>It seems that the existing derived type mechanism augmented to
>>>allow components that are declared as bit-resolution objects would
>>>suffice. Each such type would then have its principal operations
>>>defined according to the characteristics you desire. Again, nothing
>>>to do with "strings", bit or otherwise.
>
> ...
>
>>They CAN be related in that I want to be able to define the number of
>>bits that constitute a type that I am defining to be substring of a
>>bit string. This reduces impact to existing, native language features
>>(native types, kind system).
>
>
> Why couldn't it be a slice of an array or a component of a derived
> type? Why "string" particularly? Especially since Fortran doesn't
> have such a feature and it would, in itself, constitute a big impact
> on the language. Even with the new BIT type: you can create arrays
> of it; you can make it a type component, but you can't make strings
> of it. The string mechanism of Fortran is bound very tightly to the
> CHARACTER data type. (I think it shouldn't be, but that's another
> thread.)
>

What I would like to do is:

1) Define an overall packed string of bits (internally defined to the
nearest byte or smallest efficient or convenient boundary).

2) Optionally define subcomponents of that larger string to be various
invented datatypes that I build up by defining low level specifics such
as start and end of the new object in bits (relative to the total string
defined in step 1 (and all of the numerical, boolean, character or other
characteristics and attributes that I might want to assign to that
subcomponent), without regard to execution efficiency, packing
efficiency being the primary goal because they will optionally overlay a
memory mapped device area. Starting area can be on a natural boundary
(byte word), doesn't matter. None of this prevents me from defining an
entity that matches the underlying hardware archtecture and provides
maximum efficiency, but I shouldn't be limited. If I want to be able to
define a 256 bit integer type, I could (I be fine with limit of say 256
or 512 or 1024 or whatever is practical to support but I think 256 a
minimum). However, If I defined bits 1-11 to be the boundary of one
component (say an 11-bit integer), then the next definition must start
at bit 12 (could be defined as the next 3 bit integer, or could be
defined as spare or reserved, but regardless, fully definable by the
application programmer.

Anyway, I wish I could adequately describe what I want. Obviously, I've
failed several times.

Sebastian Hanigk

unread,
Mar 13, 2007, 6:16:27 AM3/13/07
to
Dan Nagle <dann...@verizon.net> writes:

>> ick. how can anyone even live without good arrays?!?
>
> How 'bout: With a Really Neat (tm) Class Structure? ;-)

Different target group? I surmise that scientific/number crunching
application development was not really a big concern in C++'s
beginning, I believe it was more or less the goal to provide an
object-oriented "layer" over C - but I favour Objective-C's approach
(messages sent to objects, like SmallTalk) over the C++/Java mechanism
(calling object's methods).


Sebastian

Craig Powers

unread,
Mar 13, 2007, 3:03:34 PM3/13/07
to
Gary Scott wrote:
>
> ick. how can anyone even live without good arrays?!?

Just fine, when all you need is vectors, deques, sets, or maps.

Kevin G. Rhoads

unread,
Mar 14, 2007, 2:54:41 PM3/14/07
to
How about:

The existence of a support group (i.e., clf) in which questions actually get answered and not flamed.

Richard Harter

unread,
Mar 14, 2007, 4:27:09 PM3/14/07
to

Chortle. Been following comp.lang.c, have we?

Kevin G. Rhoads

unread,
Mar 14, 2007, 4:47:18 PM3/14/07
to
>Chortle. Been following comp.lang.c, have we?

Not for over a decade. In their attempts to control the noise to signal ratio,
they have raised the flame to signal ratio beyond my tolerance level.

But that was indeed the experience that prompted the comment.

glen herrmannsfeldt

unread,
Mar 14, 2007, 6:31:33 PM3/14/07
to
Kevin G. Rhoads wrote:

>>Chortle. Been following comp.lang.c, have we?

> Not for over a decade. In their attempts to control the noise to signal ratio,
> they have raised the flame to signal ratio beyond my tolerance level.

I don't read it much anymore, but it wasn't because of the flames.
It just takes too long to read. So many posts don't really have
anything to do with C, other than that the ask about a program that
might have been written in C. (MS Windows, for example.)

> But that was indeed the experience that prompted the comment.

-- glen

Beliavsky

unread,
Mar 15, 2007, 6:51:34 PM3/15/07
to
On Mar 12, 1:41 pm, "Alinabi" <alexander.the.aver...@gmail.com> wrote:

<snip>

> The KIND mechanism of Fortran has seen better incarnations in other


> languages (e.g. Ada), so it is not a merit of Fortran, unless you only
> compare it to C.

Steve Lionel, of Digital/Compaq/Intel Visual Fortran fame, recently
wrote that Ada is his favorite language, describing some of its
strengths.

"What's the relevance of Ada to Fortran? Some of the major Fortran 90
features, such as modules and generics, are derived at least in part
from Ada. Fortran's separate compilation model made it difficult to
implement one of Ada's most elegant module features, IS SEPARATE,
which permitted the implementation of a module procedure to be
compiled separately from its declaration. The "submodules" proposal
for Fortran 2008 finally brings that to the language.

So what's my second favorite language? SNOBOL."

His full post is at http://softwareblogs.intel.com/2007/03/05/a-farewell-to-jean/
.

Toon Moene

unread,
Mar 20, 2007, 7:12:05 PM3/20/07
to
Pierre Asselin wrote:

> Richard Harter <c...@tiac.net> wrote:
>
>> This is a general question for the group. Fortran is widely perceived
>> as being a superior language for numeric and scientific programming.
>> What are the features and aspects that make it so.
>

> I'd say better optimization.

Last year, around this time, I figured out that gcc didn't have enough
classes of this-can't-alias-that options.

It turned out that none of the (C-expert programmers) of gcc had thought
that there would exist programming languages that - in implementation -
would use pointers to routine arguments *that could never point to local
storage*.

Well, why not - in C you can easily say:

int a(int *b)
{
int c;
b = &c;
}

but you can't in Fortran - because you cannot *get* at the pointer-to-b !

--
Toon Moene - e-mail: to...@moene.indiv.nluug.nl - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
At home: http://moene.indiv.nluug.nl/~toon/
Who's working on GNU Fortran:
http://gcc.gnu.org/ml/gcc/2007-01/msg00059.html

Pierre Asselin

unread,
Mar 21, 2007, 11:10:53 AM3/21/07
to
Toon Moene <to...@moene.indiv.nluug.nl> wrote:
> Pierre Asselin wrote:

> > Richard Harter <c...@tiac.net> wrote:
> >
> >> This is a general question for the group. Fortran is widely perceived
> >> as being a superior language for numeric and scientific programming.
> >> What are the features and aspects that make it so.
> >
> > I'd say better optimization.

> Last year, around this time, I figured out that gcc didn't have enough
> classes of this-can't-alias-that options.

Did you try the C99 "restrict" pointers ? To take your example,

int a(int * restrict b) /* added qualifier */
{
int c;
b = &c; /* now undefined behavior, don't do that */

/* however, */
{
int * restrict bb= &c;
/* bb is OK if you don't use c in this inner block */
}
}

The "restrict b" is an assertion by the programmer that b doesn't
point to anything that is used in the enclosing block. Not global
variables, not int members of global structs, and not local variables
either. If you deliberately hitch b to something else you lie to
the compiler and the optimizer has leave to take revenge. Much
like Fortran when you break its aliasing rules.

The question is, how well does that work with real C compilers.

Now I have a Fortran question. The Fortran model is that things
are not aliased unless declared pointer or target, in which
case the compile must make pessimistic assumptions just like
C. My question: is there a way to temporarily lose the stigma
of targetness ?

real, dimension(100), target:: x
real, target:: y
real, pointer :: py
interface
subroutine init(n, array, ptr)
integer n
real, dimension(n), intent(out):: array ! NOT target
real, pointer :: ptr
end subroutine init
end interface

y= 0
py=> y

! I hereby declare that py is NOT aliased to x(*)
call init(100, x, py) ! Legal ?

Is it legal to pass a target to a subroutine that expects a
non-target, as I just did above ? I want the optimizer to
give the routine its best shot and I take responsibility
to avoid aliasing when I call it.


--
pa at panix dot com

Michael Metcalf

unread,
Mar 21, 2007, 11:22:38 AM3/21/07
to

"Pierre Asselin" <p...@see.signature.invalid> wrote in message
news:etrhtt$25b$1...@reader2.panix.com...

>
> Is it legal to pass a target to a subroutine that expects a
> non-target, as I just did above ?

Yes, see MR&C Section 5.7.3.

Regardfs,

Mike Metcalf


FX

unread,
Mar 21, 2007, 12:08:08 PM3/21/07
to
>> Last year, around this time, I figured out that gcc didn't have enough
>> classes of this-can't-alias-that options.
>
> Did you try the C99 "restrict" pointers ?

It can be useful, but it's not the same. Toon (IIUC) is saying that
between "can-alias-with-nothing" and "can-alias-with-anything", there is
no model in GCC (because there's no model in C) for a
"can't-alias-with-local-variables".

--
FX

Pierre Asselin

unread,
Mar 22, 2007, 12:44:14 PM3/22/07
to
FX <cou...@alussinan.org> wrote:
> >
> > Did you try the C99 "restrict" pointers ?

> It can be useful, but it's not the same. Toon (IIUC) is saying that
> between "can-alias-with-nothing" and "can-alias-with-anything", there is
> no model in GCC (because there's no model in C) for a
> "can't-alias-with-local-variables".

That's misleading, as there is a "can't-alias-with-local-variables-
whose-address-is-never-taken". I can't quote chapter and verse
in the C standard and I'm not about to do it in this newsgroup, but
I'm pretty sure what I said is true.

Toon Moene

unread,
Mar 22, 2007, 4:49:12 PM3/22/07
to
Pierre Asselin wrote:

Sure. But what my addition did was to add an option to specify that -
for Fortran - this was *always* true, i.e., didn't need analysis,
because the Standard guaranteed it, because the address of a local
variable cannot be taken in a way that it would conflict with the
address used for referencing the dummy argument.

Pierre Asselin

unread,
Mar 23, 2007, 9:52:39 AM3/23/07
to
Toon Moene <to...@moene.indiv.nluug.nl> wrote:
> Pierre Asselin wrote:

> > FX <cou...@alussinan.org> wrote:
> >>> Did you try the C99 "restrict" pointers ?
> >
> >> It can be useful, but it's not the same. Toon (IIUC) is saying that
> >> between "can-alias-with-nothing" and "can-alias-with-anything", there is
> >> no model in GCC (because there's no model in C) for a
> >> "can't-alias-with-local-variables".
> >
> > That's misleading, as there is a "can't-alias-with-local-variables-
> > whose-address-is-never-taken". I can't quote chapter and verse
> > in the C standard and I'm not about to do it in this newsgroup, but
> > I'm pretty sure what I said is true.

> Sure. But what my addition did was to add an option to specify that -
> for Fortran - this was *always* true, i.e., didn't need analysis,
> because the Standard guaranteed it, because the address of a local
> variable cannot be taken in a way that it would conflict with the
> address used for referencing the dummy argument.

OK, I think I understand. You're working on the gfortran front-end,
you analyze code such as

integer function a(b)
integer b
use bag_of_integers, only: c, d, e
integer, target:: x, y, z
! blabla
end function b

and the back-end has no option for "b can't alias x,y,z
but may still alias c,d,e" ?

This would mean that Fortran still has an optimization edge
over C99, even with the latter's "restrict" qualifiers.

highegg

unread,
Mar 23, 2007, 11:16:04 AM3/23/07
to

> OK, I think I understand. You're working on the gfortran front-end,
> you analyze code such as
>
> integer function a(b)
> integer b
> use bag_of_integers, only: c, d, e
> integer, target:: x, y, z
> ! blabla
> end function b
>
> and the back-end has no option for "b can't alias x,y,z
> but may still alias c,d,e" ?

Actually, Fortran says more. If B aliases C (or D,E), and neither of
them is defined in the function, it's fine, otherwise, it is only B
that can be defined, and C must not even be referenced in that case.

> This would mean that Fortran still has an optimization edge
> over C99, even with the latter's "restrict" qualifiers.

That's quite likely. The Golden rule of Fortran that arguments are
unaliased can be used effectively to tell the compiler that something
is unaliased. for instance, if X and Y are pointers, but you're sure
they're not aliased, then instead of

Y = Y + pi*X

it may be more effective to use

call axpy(pi,X,Y)
...
elemental function axpy(a,x,y)
real,intent(in):: a,x
real,intent(out):: y
y = y + a*x
end function

because the former may cause a temporary copy. However, one should do
such things only in real hotspots, as it makes the code somewhat
clumsy. Notice that a DO loop
do i=1,size(Y)
Y(i) = Y(i) + pi*X
end do
is NOT an equivalent solution.

Fortran's array facilities also allow for other specific optimizations
that are not possible in other languages, like a CSE for array
expressions.

Pierre Asselin

unread,
Mar 27, 2007, 10:37:11 AM3/27/07
to
highegg <hig...@gmail.com> wrote:

> I (pa at panix.com) wrote:
> >
> > integer function a(b)
> > integer b
> > use bag_of_integers, only: c, d, e

and I left out that c,d,e have the target attribute in bag_of_integers

> > integer, target:: x, y, z
> > ! blabla
> > end function b
> >

> > and the [gcc] back-end has no option for "b can't alias x,y,z


> > but may still alias c,d,e" ?

> Actually, Fortran says more. If B aliases C (or D,E), and neither of
> them is defined in the function, it's fine, otherwise, it is only B
> that can be defined, and C must not even be referenced in that case.

Then I don't understand the problem. What you said seems to match
the C99 semantics of

int c, d, e;


int a(int * restrict b)

{
int x,y,z;
/* blabla */
}

or in any case, it's darned close. What optimization opportunities
does a C99 compiler have to leave on the table ?

Reply all
Reply to author
Forward
0 new messages