Hello everybody!

I learned programming with FORTRAN, and after several years of
experience in programming from FORTRAN, BASIC, FOXPRO , CA-CLipper and
C/C++, I may ask:  What can be done in FORTRAN that cannot be done in
C/C++ or any of the previously mentioned languages? I see that C/C++
has all the necessary resources to do number crunching, is really
necessary to use FORTRAN?

Thanks in advance

Marco A. Cruz Quevedo

macruzq@todito.com (Marco A. Cruz Q.) writes:

> I learned programming with FORTRAN, and after several years of
> experience in programming from FORTRAN, BASIC, FOXPRO , CA-CLipper and
> C/C++, I may ask:  What can be done in FORTRAN that cannot be done in
> C/C++ or any of the previously mentioned languages? I see that C/C++
> has all the necessary resources to do number crunching, is really
> necessary to use FORTRAN?

I'm not going to give a real answer because this kind of question
doesn't result in anything except flame wars.  I will generously
assume that wasn't your intention, but that's the usual outcome of
such questions, whether it was their intent or not.  I'll just play
Socrates and respond with another question.

What can be done in C/C++ or any of the other mentiond languages that
caannot be done in Fortran?  Is it really necessary to use those other
languages?

The answer, of course, to both your question and mine is that there
is nothing that can't be done and that no, none of those languages are
necessary.  Turing long ago proved that every computation that can be
done in any finite machine can be done on his imaginary Turing machine.

Thus the question of what cannot be done in a language is just not a
very interesting question.  That isn't even a significant issue for
language selection.  If it were, we'd still be programming in assembly
language or lower.

As to why people program in Fortran, or any other language, that's a
deeper question, but it is one you didn't ask and one that incites
flame wars.  I'll just say that some people find it easier than the
other choices.  My personal productivity in Fortran is approximately
a factor of 10 better than in C.  And in C++, my productivity is
essentially zero.  With other people, the numbers will be different...
and fo rother people teh best choices are different.

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

On 29 Jun 2004 15:21:35 -0700, macruzq@todito.com (Marco A. Cruz Q.)
wrote:

>I learned programming with FORTRAN, and after several years of
>experience in programming from FORTRAN, BASIC, FOXPRO , CA-CLipper and
>C/C++, I may ask:  What can be done in FORTRAN that cannot be done in
>C/C++ or any of the previously mentioned languages? I see that C/C++
>has all the necessary resources to do number crunching, is really
>necessary to use FORTRAN?

You can write a program without having to learn C++.

"Marco A. Cruz Q." wrote:
> 
> Hello everybody!
> 
> I learned programming with FORTRAN, and after several years of
> experience in programming from FORTRAN, BASIC, FOXPRO , CA-CLipper and
> C/C++, I may ask:  What can be done in FORTRAN that cannot be done in
> C/C++ or any of the previously mentioned languages? I see that C/C++
> has all the necessary resources to do number crunching, is really
> necessary to use FORTRAN?

Well in fact there are things that can't be done as conveniently as in
Fortran.  They may involve built in intrinsics that are available in
Fortran but not in C/C++.  Fortran's Syntax may be better suited for
numerical calculation.  You can say the same thing about Ada.  Ada is
often described as a superior, well designed language (although not very
appealing to me personally).  Almost every language is better at one
thing or another or suits the user's "conceptual model of the world"
better in some way.  One of the key advantages of Fortran is that it's
design inherently allows (and usually achieves, but doesn't guarantee)
typically higher levels of optimization than most competing languages. 
Since you're using FORTRAN in all upper case, I would tend to guess that
you're referring to FORTRAN 77.  Fortran 95 and soon Fortran 2003
significantly "close the gap" between Fortran and most competing
languages (lot's of debate on what those gaps actually are).

> 
> Thanks in advance
> 
> Marco A. Cruz Quevedo


-- 

Gary Scott
mailto:garyscott@ev1.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

Why are there two?  God only knows.

Democracy is two wolves and a sheep, voting on what to eat for dinner...
Liberty is a well armed sheep contesting the vote. - Thomas Jefferson

Marco A. Cruz Q. wrote:

> I learned programming with FORTRAN
> and, after several years of experience
> in programming [in] FORTRAN, BASIC, FOXPRO, CA-CLipper and C/C++,
> I may ask:  What can be done in FORTRAN that cannot be done
> in C/C++ or any of the previously mentioned languages?
> I see that C/C++ has all the necessary resources to do number crunching.
> Is it really necessary to use FORTRAN?

No.

"E. Robert Tisdale" <E.Robert.Tisdale@jpl.nasa.gov> wrote in message
news:cbt63g$cfr$1@nntp1.jpl.nasa.gov...
> Marco A. Cruz Q. wrote:
>
> > I learned programming with FORTRAN
> > and, after several years of experience
> > in programming [in] FORTRAN, BASIC, FOXPRO, CA-CLipper and C/C++,
> > I may ask:  What can be done in FORTRAN that cannot be done
> > in C/C++ or any of the previously mentioned languages?
> > I see that C/C++ has all the necessary resources to do number
crunching.
> > Is it really necessary to use FORTRAN?
>
> No.

Agreed.

-- 
You're Welcome,
Gerry T.
______
"Today's C++ programs will be tomorrow's unmaintainable legacy code." --Ian
Joyner, in a Critique of C++, 3rd ed., 1996.

Marco A. Cruz Q. wrote:

> I learned programming with FORTRAN, and after several years of
> experience in programming from FORTRAN, BASIC, FOXPRO , CA-CLipper and
> C/C++, I may ask:  What can be done in FORTRAN that cannot be done in
> C/C++ or any of the previously mentioned languages? I see that C/C++
> has all the necessary resources to do number crunching, is really
> necessary to use FORTRAN?

Do note that C and C++ are very different languages, C++ may
be more different from C than C is from Fortran.
(Depending on the weight given to various features of each.)

Others have given fine answers.

To me, there are many existing subroutine libraries already
written in Fortran.  It is possible to call them from other
languages, such as C or C++, but not portably, and not always
easily.

Some optimizations can be done by Fortran compilers, but not
by C or C++ compilers, because of the different rules on aliasing.

Some people find on or the other more readable.

-- glen

"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
news:1tpEc.2019$7t3.1384@attbi_s51...
> Marco A. Cruz Q. wrote:
>
> > I learned programming with FORTRAN, and after several years of
> > experience in programming from FORTRAN, BASIC, FOXPRO , CA-CLipper and
> > C/C++, I may ask:  What can be done in FORTRAN that cannot be done in
> > C/C++ or any of the previously mentioned languages? I see that C/C++
> > has all the necessary resources to do number crunching, is really
> > necessary to use FORTRAN?
>
> Do note that C and C++ are very different languages, C++ may
> be more different from C than C is from Fortran.
> (Depending on the weight given to various features of each.)
>
> Others have given fine answers.
>
> To me, there are many existing subroutine libraries already
> written in Fortran.  It is possible to call them from other
> languages, such as C or C++, but not portably, and not always
> easily.
>
> Some optimizations can be done by Fortran compilers, but not
> by C or C++ compilers, because of the different rules on aliasing.

This is a myth. It just isn't true as far as C/C++ is concerned so please
stop this Fortran prepaganda, it doesn't wash, sorry.

In what language(s) are Fortran compilers written in (tough!) ?

>
> Some people find on or the other more readable.
>
> -- glen
>

"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
news:1tpEc.2019$7t3.1384@attbi_s51...
> Marco A. Cruz Q. wrote:
> Do note that C and C++ are very different languages, C++ may
> be more different from C than C is from Fortran.
.......
> Some optimizations can be done by Fortran compilers, but not
> by C or C++ compilers, because of the different rules on aliasing.
The aliasing rules of C and C++ differ.   Using the C anti-aliasing
facilities in C++ is non-standard.
> Some people find on or the other more readable.
>
Those C anti-aliasing facilities promote lack of readability.  No doubt,
that has some influence on the lack of adoption in C++.

"Tim Prince" <tprince@computer.org> wrote in message
news:P_pEc.79460$cB2.43773@newssvr29.news.prodigy.com...
>
> "glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
> news:1tpEc.2019$7t3.1384@attbi_s51...
> > Marco A. Cruz Q. wrote:
> > Do note that C and C++ are very different languages, C++ may
> > be more different from C than C is from Fortran.
> ......
> > Some optimizations can be done by Fortran compilers, but not
> > by C or C++ compilers, because of the different rules on aliasing.
> The aliasing rules of C and C++ differ.   Using the C anti-aliasing
> facilities in C++ is non-standard.
> > Some people find on or the other more readable.
> >
> Those C anti-aliasing facilities promote lack of readability.  No doubt,
> that has some influence on the lack of adoption in C++.
>
>

Strawman.

-- 
You're Welcome,
Gerry T.
______
"Things are not what they seem; or, to be more accurate, they are not only
what they seem, but very much else besides." -- Aldous Huxley.

Richard Maine <nospam@see.signature> wrote in message news:<m1vfhayoqq.fsf@macfortran.local>...
> macruzq@todito.com (Marco A. Cruz Q.) writes:
> 
> > I learned programming with FORTRAN, and after several years of
> > experience in programming from FORTRAN, BASIC, FOXPRO , CA-CLipper and
> > C/C++, I may ask:  What can be done in FORTRAN that cannot be done in
> > C/C++ or any of the previously mentioned languages? I see that C/C++
> > has all the necessary resources to do number crunching, is really
> > necessary to use FORTRAN?
> 
> I'm not going to give a real answer because this kind of question
> doesn't result in anything except flame wars.  I will generously
> assume that wasn't your intention, but that's the usual outcome of
> such questions, whether it was their intent or not.  I'll just play
> Socrates and respond with another question.
> 
> What can be done in C/C++ or any of the other mentiond languages that
> caannot be done in Fortran?  Is it really necessary to use those other
> languages?
> 
> The answer, of course, to both your question and mine is that there
> is nothing that can't be done and that no, none of those languages are
> necessary.  Turing long ago proved that every computation that can be
> done in any finite machine can be done on his imaginary Turing machine.
> 
> Thus the question of what cannot be done in a language is just not a
> very interesting question.  That isn't even a significant issue for
> language selection.  If it were, we'd still be programming in assembly
> language or lower.
> 
> As to why people program in Fortran, or any other language, that's a
> deeper question, but it is one you didn't ask and one that incites
> flame wars.  I'll just say that some people find it easier than the
> other choices.  My personal productivity in Fortran is approximately
> a factor of 10 better than in C.  And in C++, my productivity is
> essentially zero.  With other people, the numbers will be different...
> and fo rother people teh best choices are different.

Of course I do not want flame wars! Simply, after having written
programs in several languages, I cannot find a reason to keep
programming in FORTRAN (which I like very much). I can do a matrix
inverse in C/C++or even in Qbasic (compiled). And with the today's
processors, this can be done very reliably. So it comes the question:
What is REALLY FORTRAN good at? Everything can be done in C/C++! Give
me a task that rather MUST be done in FORTRAN

Regards

Marco A. Cruz Quevedo

Gerry Thomas wrote:
> "glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
> news:1tpEc.2019$7t3.1384@attbi_s51...
....
>> Some optimizations can be done by Fortran compilers, but not
>> by C or C++ compilers, because of the different rules on aliasing.
>
> This is a myth. It just isn't true as far as C/C++ is concerned so please
> stop this Fortran prepaganda, it doesn't wash, sorry.
>
> In what language(s) are Fortran compilers written in (tough!) ?

The produced code is machine code.  The language the compiler
is written may be completely incapable of itself being optimized
in way that it can optimize the Fortran it is processing.

The statement that aliasing inhibits optimization is simply true.
There are literally *decades* of papers (CACM, SIGPLAN, etc.)
on the issues of optimizing in the presence of aliasing - many
in an effort to get C performance up to the standard set by Fortran.
Or, does your word "prepaganda" mean something that *is*
true and doesn't need a wash?

The statement that C/C++ can't be optimized as well as Fortran
was true until C99 (and, unless you religiously use 'restricted'
and 'register' attributes, it's still true).  I don't think C++ has the
requisite features even now.

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

On 29 Jun 2004 20:56:29 -0700, macruzq@todito.com (Marco A. Cruz Q.)
wrote:


>Of course I do not want flame wars! Simply, after having written
>programs in several languages, I cannot find a reason to keep
>programming in FORTRAN (which I like very much). I can do a matrix
[snip]

Isn't liking it enough for you?

I know that I don't have to eat steak.  I can get nourishment from
chicken, pork, tofu, Soylent green, etc.  But I like steak, and will
continue to eat it.  And I will continue to enjoy meal time.

YMMV

Ken Plotkin

"Ken Plotkin" <kplotkin@nospam-cox.net> wrote in message
news:5rg4e0purgomhh2dbb5urlj54un5apmb5u@4ax.com...
> On 29 Jun 2004 20:56:29 -0700, macruzq@todito.com (Marco A. Cruz Q.)
> wrote:
>
>
> >Of course I do not want flame wars! Simply, after having written
> >programs in several languages, I cannot find a reason to keep
> >programming in FORTRAN (which I like very much). I can do a matrix
> [snip]
>
> Isn't liking it enough for you?
>
> I know that I don't have to eat steak.  I can get nourishment from
> chicken, pork, tofu, Soylent green, etc.  But I like steak, and will
> continue to eat it.  And I will continue to enjoy meal time.
>
> YMMV
>
> Ken Plotkin

Ken,

Ralph Kline would be happy to arrange for a few on the hoof of the best
that Alberta has to offer, they might be a bit off their rockers (sic MAD)
but at least you can always milk them for cheap gas. Enjoy if they show up,
UPS has the inside track IIRC.

-- 
Ciao,
Gerry T.

"James Giles" <jamesgiles@worldnet.att.net> wrote in message
news:q7rEc.43728$OB3.32202@bgtnsc05-news.ops.worldnet.att.net...
> Gerry Thomas wrote:
> > "glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
> > news:1tpEc.2019$7t3.1384@attbi_s51...
> ...
> >> Some optimizations can be done by Fortran compilers, but not
> >> by C or C++ compilers, because of the different rules on aliasing.
> >
> > This is a myth. It just isn't true as far as C/C++ is concerned so
please
> > stop this Fortran prepaganda, it doesn't wash, sorry.
> >
> > In what language(s) are Fortran compilers written in (tough!) ?
>
> The produced code is machine code.

> The language the compiler
> is written may be completely incapable of itself being optimized
> in way that it can optimize the Fortran it is processing.

Giles, again I endow you with more intelligence than you perhaps deserve,
but your last statement isn't a sentence in English, Fortran, machine
language, or applied Urdu for all I know or care, so please, go back to ug
ug and perhaps we can start communicating.

>
> The statement that aliasing inhibits optimization is simply true.

It was true, the operative being was.

> There are literally *decades* of papers (CACM, SIGPLAN, etc.)
> on the issues of optimizing in the presence of aliasing - many
> in an effort to get C performance up to the standard set by Fortran.

All these 'papers' have been relugated to the trash can, minor milestones
of progress, but now that we've arrived somewhat, they're intellectual
garbish, perhaps some future 'scholar' eons hence will dig them up and pen
an erudite paper on what it was like way back when but don't put the house
on it,

> Or, does your word "prepaganda" mean something that *is*
> true and doesn't need a wash?
>

I ought to fourwardy all my c.l.f. misivees troue you or anoder fourtran
autoritty for priore aprovaale as you apeare to have a fixxxation withe me
porpusefully and intenntionally speling mistackes but with my felicity of
diction and condensation of thought that you or anyone else here can't
match why should I care what you and others think of my spelling or
anything else for that matter. I don't, simple as that.

> The statement that C/C++ can't be optimized as well as Fortran
> was true until C99 (and, unless you religiously use 'restricted'
> and 'register' attributes, it's still true).  I don't think C++ has the
> requisite features even now.
>

Disagree.

-- 
You're Welcome,
Gerry T.
______
"Today's C++ programs will be tomorrow's unmaintainable legacy code." --Ian
Joyner, in a Critique of C++, 3rd ed., 1996.

Gerry Thomas wrote:

> James Giles wrote:
> 
>>The statement that C/C++ can't be optimized as well as Fortran
>>was true until C99 (and, 
>> unless you religiously use 'restricted' and 'register' attributes,  
>> it's still true). 
>>I don't think C++ has the requisite features even now.
> 
> Disagree.

The 'restrict' keyword introduced in C 99
permits C 99 compilers to perform the same "optimizations" on C arrays
as are permitted on Fortran arrays
*and* implies *all* of the same hazards.

It appears that the C++ '03 standard will subsume *all*
of the new features adopted by the C 99 standard
including the syntax and semantics of the 'restrict' keyword.

Many C++ compilers already provide support for the 'restrict' semantics.
My GNU C++ compiler recognizes the '__restrict__' keyword, for example.

Note that C programmers have always had the option
of hand-coding the optimizations
that Fortran compilers perform on arrays.

Gerry Thomas wrote:
> "James Giles" <jamesgiles@worldnet.att.net> wrote in message
> news:q7rEc.43728$OB3.32202@bgtnsc05-news.ops.worldnet.att.net...
....
>> The statement that aliasing inhibits optimization is simply true.
>
> It was true, the operative being was.

It *IS* true.  The operative being *IS*.  But, you go ahead and
try your luck writing your rebuttal into *any* peer reviewed
journal on computing.  I'm sure they could use a good laugh.

>> The statement that C/C++ can't be optimized as well as Fortran
>> was true until C99 (and, unless you religiously use 'restricted'
>> and 'register' attributes, it's still true).  I don't think C++ has the
>> requisite features even now.
>>
>
> Disagree.


I don't care.  I'm only interested in what you actually have
objective evidence of.  All your diatribes don't add up to
even a single sentence of evidence.  Data flow in language
implementation is a fairly well known subject, for everyone
except, apparently, you.  But, if  C were so easy to optimize,
why did the committee feel it necessary to add the restrict
qualifier to the language at all?

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

Oh, I missed you signature quote:

> "Today's C++ programs will be tomorrow's unmaintainable legacy code." --Ian
> Joyner, in a Critique of C++, 3rd ed., 1996.

In my experience, today's C++ programs are *today's*
unmaintainable legacy code.  It isn't a very good language
if legibility and maintenence is important.

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

"James Giles" <jamesgiles@worldnet.att.net> wrote in message
news:VfsEc.43912$OB3.14332@bgtnsc05-news.ops.worldnet.att.net...
> Gerry Thomas wrote:
> > "James Giles" <jamesgiles@worldnet.att.net> wrote in message
> > news:q7rEc.43728$OB3.32202@bgtnsc05-news.ops.worldnet.att.net...
> ...
> >> The statement that aliasing inhibits optimization is simply true.
> >
> > It was true, the operative being was.
>
> It *IS* true.

Sorry, it IS NOT so.
At this point, we disagree, finito.

> The operative being *IS*.  But, you go ahead and
> try your luck writing your rebuttal into *any* peer reviewed
> journal on computing.  I'm sure they could use a good laugh.
>

I could care less what these old farts smell other than themselves.

> >> The statement that C/C++ can't be optimized as well as Fortran
> >> was true until C99 (and, unless you religiously use 'restricted'
> >> and 'register' attributes, it's still true).  I don't think C++ has
the
> >> requisite features even now.
> >>
> >
> > Disagree.
>
>
> I don't care.

Touch� my boy, and I suspect like all of your crusades, neither does anyone
else.
I do multilanguage (4+) programming on a daily basis and not once has your
highfalutin bullshit been one iota of help in this regard.

Giles, not only are you a strawman, are you a tin man. So don't go wetting
yourself, but I suspect that you're already rusted right through.

-- 
Bye,
Gerry T.

Gerry Thomas wrote:

(snip)

> In what language(s) are Fortran compilers written in (tough!) ?

I do know one that is (mostly) written in Fortran, if
that is what you are asking.  Most newer ones aren't, though.

-- glen

Gerry Thomas wrote:
> "James Giles" <jamesgiles@worldnet.att.net> wrote in message
> news:VfsEc.43912$OB3.14332@bgtnsc05-news.ops.worldnet.att.net...
>> Gerry Thomas wrote:
>>> "James Giles" <jamesgiles@worldnet.att.net> wrote in message
>>> news:q7rEc.43728$OB3.32202@bgtnsc05-news.ops.worldnet.att.net...
>> ...
>>>> The statement that aliasing inhibits optimization is simply true.
>>>
>>> It was true, the operative being was.
>>
>> It *IS* true.
>
> Sorry, it IS NOT so.
> At this point, we disagree, finito.

Except that the objective evidence is all on my side.  I just
looked: the online lecture notes for the currect compiler
construction courses at several major universities list
aliasing as a major cause of optimization inhibition.

Given the fact that you have mentioned *no* objective
evidence to support your position, it appears that, as
usual, you are blowing smoke.

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

James Giles wrote:

> Given the fact that you have mentioned *no* objective
> evidence to support your position, it appears that, as
> usual, you are blowing smoke.
> 

What's new ? :)

-- 
PHONOGRAPH, n.  An irritating toy that restores life to dead noises.

 --- from The Devil's Dictionary, Ambrose Bierce

"James Giles" <jamesgiles@worldnet.att.net> wrote in message
news:pZsEc.44017$OB3.36553@bgtnsc05-news.ops.worldnet.att.net...
> Gerry Thomas wrote:
> > "James Giles" <jamesgiles@worldnet.att.net> wrote in message
> > news:VfsEc.43912$OB3.14332@bgtnsc05-news.ops.worldnet.att.net...
> >> Gerry Thomas wrote:
> >>> "James Giles" <jamesgiles@worldnet.att.net> wrote in message
> >>> news:q7rEc.43728$OB3.32202@bgtnsc05-news.ops.worldnet.att.net...
> >> ...
> >>>> The statement that aliasing inhibits optimization is simply true.
> >>>
> >>> It was true, the operative being was.
> >>
> >> It *IS* true.
> >
> > Sorry, it IS NOT so.
> > At this point, we disagree, finito.
>
> Except that the objective evidence is all on my side.

Good for you. This is your objective evidence, not mine. To me, whatever
you're babbling on about it's undoubtedly outdated baloney, a waste of
starch. Bunk, just like history.

 > Given the fact that you have mentioned *no* objective
> evidence to support your position, it appears that, as
> usual, you are blowing smoke.
>

You don't seem to understand what 'evidence' means and I'm not about to
teach you.
I suspect you're into the single malt again, so save face and call it a
night, OK.

-- 
Bye,
Gerry T.

"Madhusudan Singh" <spammers-go-here@yahoo.com> wrote in message
news:2kf5f9F1ln8sU1@uni-berlin.de...
> James Giles wrote:
>
> > Given the fact that you have mentioned *no* objective
> > evidence to support your position, it appears that, as
> > usual, you are blowing smoke.
> >
>
> What's new ? :)

The Rag Head emerges, why? Still has nothing to say.

-- 
You're Welcome,
Gerry T.
______________________________________
"Indians are not niggers, they're wogs,,." -- The Maj. in Fawlty Towers.

"Marco A. Cruz Q." <macruzq@todito.com> wrote in message
news:12796de5.0406291421.37dca67a@posting.google.com...

> I learned programming with FORTRAN, and after several years of
> experience in programming from FORTRAN, BASIC, FOXPRO , CA-CLipper and
> C/C++, I may ask:  What can be done in FORTRAN that cannot be done in
> C/C++ or any of the previously mentioned languages? I see that C/C++
> has all the necessary resources to do number crunching, is really
> necessary to use FORTRAN?

Oh man!  I've been writing Fortran all evening so I missed this
flame war up to now.  Here, have a look at some of the Fortran
I wrote this evening:

! File: gen31a.f90
! Public domain 2004 James Van Buskirk
module mykinds
   implicit none
   integer, parameter :: dp = selected_real_kind(15,300)
   integer, parameter :: qp_preferred = selected_real_kind(30,1000)
   integer, parameter :: qp = (1+sign(1,qp_preferred))/2*qp_preferred+ &
                              (1-sign(1,qp_preferred))/2*dp
end module mykinds

module tensors
   use mykinds
   implicit none
   interface operator(.tensor.)
      module procedure tensor_product
   end interface operator(.tensor.)
   interface operator(.plus.)
      module procedure direct_sum
   end interface operator(.plus.)
   contains
      function tensor_product(A1,A2)
         real(qp), intent(in) :: A1(:,:)
         real(qp), intent(in) :: A2(:,:)
         real(qp)
tensor_product(size(A1,1)*size(A2,1),size(A1,2)*size(A2,2))
         integer i1, i2, j1, j2

         do i1 = 1, size(A1,1)
            do i2 = 1, size(A2,1)
               do j1 = 1, size(A1,2)
                  do j2 = 1, size(A2,2)

tensor_product((i1-1)*size(A2,1)+i2,(j1-1)*size(A2,2)+j2) = &
                        A1(i1,j1)*A2(i2,j2)
                  end do
               end do
            end do
         end do
      end function tensor_product

      function direct_sum(A1,A2)
         real(qp), intent(in) :: A1(:,:)
         real(qp), intent(in) :: A2(:,:)
         real(qp) direct_sum(size(A1,1)+size(A2,1),size(A1,2)+size(A2,2))

         direct_sum = 0
         direct_sum(1:size(A1,1),1:size(A1,2)) = A1
         direct_sum(size(A1,1)+1:,size(A1,2)+1:) = A2
      end function direct_sum

      function identity(n)
         integer, intent(in) :: n
         real(qp) identity(n,n)
         integer i

         identity = 0
         do i = 1, n
            identity(i,i) = 1
         end do
      end function identity
end module tensors

program gen31a
   use mykinds
   use tensors
   implicit none
   integer, parameter :: N = 31
   integer, parameter :: g = 3
   integer i
   integer crow(0:N-1), ccol(0:N-1)
   character(80) ifmt
   integer mc(N,N)
   integer g3, g5, g2
   integer j
   integer k
   real(qp) pi
   real(qp) theta
   real(qp) c(0:N-1,0:N-1)
   character(80) rfmt
   real(qp) rf2i(2,2)
   real(qp) f2inv(0:N-1,0:N-1)
   real(qp) rf5i(5,5)
   real(qp) f5inv(0:N-1,0:N-1)
   real(qp) s(0:N-1,0:N-1)
   character(80) pfmt

   crow(0) = 0
   crow(1) = 1
   do i = 2, N-1
      crow(i) = modulo(g*crow(i-1),N)
   end do
   g3 = 10
   g5 = 6
   g2 = 15
   write(ifmt,'(a,i0,a)') '(',N,'(i3))'
   write(*,ifmt) crow
   crow(1:) = (/(((crow(modulo(g3*i+g5*j+g2*k,N-1)+1),i=0,2),j=0,4),k=0,1)/)
   ccol(0:1) = crow(0:1)
   ccol(2:) = crow(N-1:2:-1)
   ccol(1:) = crow(N-1:1:-1)
   write(*,ifmt) crow
   write(*,ifmt) ccol
   mc = modulo(matmul(reshape(ccol,(/N,1/)),reshape(crow,(/1,N/))),N)
   write(*,'()')
   write(*,'()') ! Work around bug in LF95 5.70d
   write(*,ifmt) transpose(mc)
   pi = 4*atan(1.0_qp)
   theta = 2*pi/N
   c = cos(theta*mc)
   write(rfmt,'(a,i0,a)') '(',N,'f7.3)'
   write(*,'()')
   write(*,'()') ! Work around bug in LF95 5.70d
   write(*,rfmt) transpose(c)
   rf2i = reshape((/1,1,1,-1/),shape(rf2i))
   rf2i = rf2i/2
   f2inv = identity(1).plus.((rf2i).tensor.identity((N-1)/2))
   c = matmul(f2inv,matmul(c,f2inv))
   write(*,'()')
   write(*,'()') ! Work around bug in LF95 5.70d
   write(*,rfmt) transpose(c)
   theta = 2*pi/5
   rf5i = reshape((/ &
     cos(0*theta), cos(0*theta), cos(0*theta), cos(0*theta), cos(0*theta), &
     cos(0*theta), cos(1*theta), cos(2*theta), cos(-2*theta), cos(-1*theta),
&
     sin(0*theta), sin(1*theta), sin(2*theta), sin(-2*theta), sin(-1*theta),
&
     cos(0*theta), cos(2*theta), cos(-1*theta), cos(1*theta), cos(-2*theta),
&
     sin(0*theta), sin(2*theta), sin(-1*theta), sin(1*theta),
sin(-2*theta)/), &
     shape(rf5i), order=(/2,1/))
   rf5i(2:4:2,:) = rf5i(2:4:2,:)/(rf5i(2,3)-rf5i(2,2))
   rf5i(3:5:2,:) = rf5i(3:5:2,:)/rf5i(3,2)
   pfmt = "(4x,'real(wp),parameter :: ',a,' = ',f0.34,'_wp')"
   write(*,'()')
   write(*,'()') ! Work around bug in LF95 5.70d
   write(*,pfmt) 'c1', rf5i(2,1)
   write(*,pfmt) 'c2', rf5i(2,2)
   write(*,pfmt) 's1', rf5i(3,3)
   forall(i=1:5) rf5i(i,:) = rf5i(i,:)/dot_product(rf5i(i,:),rf5i(i,:))
   rf5i = transpose(rf5i)
   f5inv = identity(1).plus.(rf5i.tensor.identity(3)).plus.identity((N-1)/2)
   c = matmul(transpose(f5inv),matmul(c,f5inv))
   write(*,'()')
   write(*,'()') ! Work around bug in LF95 5.70d
   write(*,rfmt) transpose(c)

   theta = 2*pi/N
   s = sin(theta*mc)
   write(*,'()')
   write(*,'()') ! Work around bug in LF95 5.70d
   write(*,rfmt) transpose(s)
   s = matmul(f2inv,matmul(s,f2inv))
   write(*,'()')
   write(*,'()') ! Work around bug in LF95 5.70d
   write(*,rfmt) transpose(s)
   f5inv = identity((N+1)/2).plus.(rf5i.tensor.identity(3))
   s = matmul(transpose(f5inv),matmul(s,f5inv))
   write(*,'()')
   write(*,'()') ! Work around bug in LF95 5.70d
   write(*,rfmt) transpose(s)

   write(*,'()')
   write(*,'()') ! Work around bug in LF95 5.70d
   write(*,pfmt) 'dc1',c(1,1)
   write(*,pfmt) 'dc2',c(1,2)-c(1,1)
   write(*,pfmt) 'dc3',c(1,3)-c(1,1)
   write(*,pfmt) 'dc4',c(4,7)
   write(*,pfmt) 'dc5',c(4,4)+c(4,7)
   write(*,pfmt) 'dc6',c(7,7)-c(4,7)
   write(*,pfmt) 'dc7',c(4,8)
   write(*,pfmt) 'dc8',c(4,5)+c(4,8)
   write(*,pfmt) 'dc9',c(7,8)-c(4,8)
   write(*,pfmt) 'dc10',c(4,9)
   write(*,pfmt) 'dc11',c(4,6)+c(4,9)
   write(*,pfmt) 'dc12',c(7,9)-c(4,9)
   write(*,pfmt) 'dc13',c(10,13)
   write(*,pfmt) 'dc14',c(10,10)+c(10,13)
   write(*,pfmt) 'dc15',c(13,13)-c(10,13)
   write(*,pfmt) 'dc16',c(10,14)
   write(*,pfmt) 'dc17',c(10,11)+c(10,14)
   write(*,pfmt) 'dc18',c(13,14)-c(10,14)
   write(*,pfmt) 'dc19',c(10,15)
   write(*,pfmt) 'dc20',c(10,12)+c(10,15)
   write(*,pfmt) 'dc21',c(13,15)-c(10,15)
   write(*,pfmt) 'ds1',s(16,16)
   write(*,pfmt) 'ds2',s(16,17)
   write(*,pfmt) 'ds3',s(16,18)
   write(*,pfmt) 'ds4',s(19,22)
   write(*,pfmt) 'ds5',s(19,19)+s(19,22)
   write(*,pfmt) 'ds6',s(22,22)-s(19,22)
   write(*,pfmt) 'ds7',s(19,23)
   write(*,pfmt) 'ds8',s(19,20)+s(19,23)
   write(*,pfmt) 'ds9',s(22,23)-s(19,23)
   write(*,pfmt) 'ds10',s(19,24)
   write(*,pfmt) 'ds11',s(19,21)+s(19,24)
   write(*,pfmt) 'ds12',s(22,24)-s(19,24)
   write(*,pfmt) 'ds13',s(25,28)
   write(*,pfmt) 'ds14',s(25,25)+s(25,28)
   write(*,pfmt) 'ds15',s(28,28)-s(25,28)
   write(*,pfmt) 'ds16',s(25,29)
   write(*,pfmt) 'ds17',s(25,26)+s(25,29)
   write(*,pfmt) 'ds18',s(28,29)-s(25,29)
   write(*,pfmt) 'ds19',s(25,30)
   write(*,pfmt) 'ds20',s(25,27)+s(25,30)
   write(*,pfmt) 'ds21',s(28,30)-s(25,30)
   pfmt = '(4x,a,z1,a,i0,a,i0,a)'
   do i = 1, (N-1)/2
      write(*,pfmt) 'xr',i,' = real(h(',crow(i),'))+real(h(',crow(i+15),'))'
      write(*,pfmt) 'xi',i,' =
aimag(h(',crow(i),'))+aimag(h(',crow(i+15),'))'
      write(*,pfmt) 'yr',i,' = real(h(',crow(i),'))-real(h(',crow(i+15),'))'
      write(*,pfmt) 'yi',i,' =
aimag(h(',crow(i),'))-aimag(h(',crow(i+15),'))'
   end do
   pfmt = '(4x,a,i0,a,z1,a,z1,a,z1,a,z1,a)'
   do i = 1, (N-1)/2
      write(*,pfmt) 'h(',ccol(i),') =
cmplx(sr',i,'+ti',i,',si',i,'-tr',i,',wp)'
      write(*,pfmt) 'h(',ccol(i+15),') =
cmplx(sr',i,'-ti',i,',si',i,'+tr',i,',wp)'
   end do
end program gen31a
! End of file: gen31a.f90

Some of the features to note in the above:
o The code allows the compiler to fall back on double
  precision if quadruple precision is not available.
o Fortran allows easy definition of .plus. and .tensor.
  operators for direct sum and tensor product of matrices.
o Fortran has intrinsic array syntax including broadcast
  of scalars, FORALL, elemental sum, elemental intrinsics,
  and matrix multiplication.

I think it would be rather tricky to emulate these features
in a small self-contained C++ program, and as a bonus it
takes one or more orders of magnitude less time to learn
Fortran than it does do learn C++.  If what one is trying
to achieve is a good match for Fortran as in the program
above, it makes sense to me to apply Fortran to the problem.

-- 
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

Gerry Thomas wrote:
> Good for you. This is your objective evidence, not mine. To me, whatever
> you're babbling on about it's undoubtedly outdated baloney, a waste of
> starch. Bunk, just like history.


The cheaper the crook, the gaudier the patter, eh?

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

"James Giles" <jamesgiles@worldnet.att.net> wrote in message
news:JytEc.163771$Gx4.151639@bgtnsc04-news.ops.worldnet.att.net...
> Gerry Thomas wrote:
> > Good for you. This is your objective evidence, not mine. To me,
whatever
> > you're babbling on about it's undoubtedly outdated baloney, a waste of
> > starch. Bunk, just like history.
>
>
> The cheaper the crook, the gaudier the patter, eh?
>

Giles, you're bombed, go to bed and sober up, you are not my verbal or
intellectual match.

-- 
You're Welcome,
Gerry T.
______
"The best lesson life has taught me is that the idiots in many cases are
right." -- Churchill.

> The 'restrict' keyword introduced in C 99
> permits C 99 compilers to perform the same "optimizations" on C arrays
> as are permitted on Fortran arrays
> *and* implies *all* of the same hazards.

Sure enough. So how many compilers implement that keyword properly,
and how many C programmers know what they mean, and can use them properly?

> Note that C programmers have always had the option
> of hand-coding the optimizations
> that Fortran compilers perform on arrays.

Yeah sure, I might as well right in assembler right away. The problem
being that both in assembler and C, I will then have commited to a
particular form of that optimization - which might be suitable to the
current situation, but what about a new processor, system, ...? In
your world I get to redo the optimization again and again and again.
In Fortran's world, I get the compiler writers to do it once, and can
automatically apply it to all my code - again, and again, and again.

	Jan

>>There are literally *decades* of papers (CACM, SIGPLAN, etc.)
>>on the issues of optimizing in the presence of aliasing - many
>>in an effort to get C performance up to the standard set by Fortran.
> All these 'papers' have been relugated to the trash can, minor milestones
> of progress, but now that we've arrived somewhat, they're intellectual
> garbish,

I must have missed the press release that you have received the Fields Medal,
as it appears that you have solved the halting problem. Congratulations!

	Jan

"Jan Vorbr�ggen" <jvorbrueggen-not@mediasec.de> wrote in message
news:2kf87pF1la8rU2@uni-berlin.de...
> >>There are literally *decades* of papers (CACM, SIGPLAN, etc.)
> >>on the issues of optimizing in the presence of aliasing - many
> >>in an effort to get C performance up to the standard set by Fortran.
> > All these 'papers' have been relugated to the trash can, minor
milestones
> > of progress, but now that we've arrived somewhat, they're intellectual
> > garbish,
>
> I must have missed the press release that you have received the Fields
Medal,
> as it appears that you have solved the halting problem. Congratulations!
>
> Jan

Clearly being as dumb as Giles doesn't come easy, but with both of you
having Picton Farm soil for brains the Field Medal (I guess it's some kind
of farmer's prize) for those displaying near human intelligence against all
probably odds is undoubtedly a first, so consider yourselves nominated
forthwith and good luck to you both.

-- 
You're Welcome,
Gerry T.
______
"Don't play dumb! You're not as good at it as I am!" -- Col Sam Flagg,
ICORPS dropin to the 4077th M*A*S*H

Marco A. Cruz Q. wrote:
> Of course I do not want flame wars!

That's nice, but these kinds of discussions tend to degenerate pretty
quickly! ;-) Witness the remark about aliasing in Fortran vs. C, which
already has caused a minor flame war. Just wait until somebody gets
the idea to crosspost the thread to comp.lang.c. :(

> Simply, after having written
> programs in several languages, I cannot find a reason to keep
> programming in FORTRAN (which I like very much).

Do you like programming in Fortran, or do you like the fact that you
cannot find a reason to keep programming in Fortran? If the former, by
all means use Fortran if you enjoy it. If the latter, perhaps you'll
find some reasons or then you'd perhaps better stop using Fortran.

> I can do a matrix
> inverse in C/C++or even in Qbasic (compiled). And with the today's
> processors, this can be done very reliably. So it comes the question:
> What is REALLY FORTRAN good at? Everything can be done in C/C++! Give
> me a task that rather MUST be done in FORTRAN

As was already mentioned, you can do any computation with any turing
complete language. If you're sufficiently masochistic, you might enjoy
writing your matrix inversion routine in Intercal.

Thus the question is not which tasks must be done in some specific
language, but rather which language best handles that task. Or if you
want a more businesslike term, which language provides the lowest tco
(total cost of ownership) for a given task. There have been plenty of
studies suggesting that producing and maintaining C/C++ programs is
quite expensive, compared to many other languages. One of the more
famous ones is the Rational study comparing C and Ada, where the
result was that using C is approximately twice as expensive as
Ada. There was also a quite big study by NASA comparing FORTRAN77 and
Ada for numerical/technical computing, where the result was that Ada
was about 30 % cheaper than F77. Considering that Fortran 90 brought
many very significant improvements related to maintainability of
larger programs such as modules, derived types etc., I think one can
assume, based on the two studies above, that for mainly
numerical/technical software, C is at least twice as expensive as F90.


-- 
Janne Blomqvist

 > the Field Medal (I guess it's some kind of farmer's prize)

ROTFL - that's a good one! But please note it is the Field_s_ Medal.
Perhaps you should look it up somewhere?

	Jan

In article <12796de5.0406291956.4bd1dfac@posting.google.com>, Marco A. 
Cruz Q. <macruzq@todito.com> writes
>Of course I do not want flame wars! Simply, after having written
>programs in several languages, I cannot find a reason to keep
>programming in FORTRAN (which I like very much). I can do a matrix
>inverse in C/C++or even in Qbasic (compiled). And with the today's
>processors, this can be done very reliably. So it comes the question:
>What is REALLY FORTRAN good at? Everything can be done in C/C++! Give
>me a task that rather MUST be done in FORTRAN
>
>Regards
>
>Marco A. Cruz Quevedo

Keep programming in it because it works for you! That's the only reason 
that matters. You can do a matrix inverse in any language you like. Many 
(including Fortran) are good at it. There is no task that must be done 
in Fortran. There is no task that must be done in C++. There is no task 
that must be done in Qbasic. Pick the one that suits you.

Why do you feel you need a reason to keep programming in Fortran? Ask 
rather, what your reason is to switch to C++. "Because it's possible to 
rewrite my Fortran code using it" doesn't seem like a very good one to 
me.

Catherine.
-- 
Catherine Rees Lay
To email me, use my first name in front of the "at".

Catherine Rees Lay wrote:
....

  Pick the one that suits you.

I agree, but I would add  " ... and your coworkers/colleagues."

A programming language is more for humans than for computers.

Giorgio

As they say, FWIW:

In 16 years of doing a few things in various flavors of C, and 43+
years of FORTRAN, I have yet to find a C or C++ compiler which
can evaluate (without further ado)  the equivalent of

Z3=Z1*SIN(Z2)

where all the variables are complex numbers.
 

Jan Vorbr�ggen <jvorbrueggen-not@mediasec.de> writes:

> I must have missed the press release that you have received the Fields Medal,
> as it appears that you have solved the halting problem. Congratulations!

It would indeed be a significant contribution to solve the halting
problem as applied to our esteemed (at least by himself, which appears
to be the only important criterion) colleague, who I shall not
dignify with naming.  :-(

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

As this topic gets more replies, one more advantage of using a 
Fortran Compiler (like Lahey's or Salford's) is robustness; that is,
good run-time diagnostics. In my experience, C++ compilers
just do not have this level of RUN-TIME diagnostics. 

Skip Knoble

On 29 Jun 2004 15:21:35 -0700, macruzq@todito.com (Marco A. Cruz Q.) wrote:

-|Hello everybody!
-|
-|I learned programming with FORTRAN, and after several years of
-|experience in programming from FORTRAN, BASIC, FOXPRO , CA-CLipper and
-|C/C++, I may ask:  What can be done in FORTRAN that cannot be done in
-|C/C++ or any of the previously mentioned languages? I see that C/C++
-|has all the necessary resources to do number crunching, is really
-|necessary to use FORTRAN?
-|
-|Thanks in advance
-|
-|Marco A. Cruz Quevedo


   Herman D. (Skip) Knoble, Research Associate
   (a computing professional for 38 years)
   Email: SkipKnobleLESS at SPAMpsu dot edu
   Web: http://www.personal.psu.edu/hdk
   Penn State Information Technology Services
    Academic Services and Emerging Technologies
     Graduate Education and Research Services
   Penn State University
     214C Computer Building
     University Park, PA 16802-21013
   Phone:+1 814 865-0818   Fax:+1 814 863-7049

In article <12796de5.0406291956.4bd1dfac@posting.google.com>, 
macruzq@todito.com says...

> I can do a matrix
> inverse in C/C++or even in Qbasic (compiled). 

I'm a Fortran newbie, so other people may answer far better than me :)

However, my opinion is that, even if you can invert matrix also in 
C/C++, if you use Fortran:

- you don't have to include headers or link custom non-standard 
libraries to do it

- you get the same result of C/C++, but in *less* time, exspecially on 
big matrices

Ciao
Dan

In article <slrnce4t6s.i3j.jblomqvi@vipunen.hut.fi>, 
jblomqvi@roskaposti.invalid says...
> Marco A. Cruz Q. wrote:
> > Of course I do not want flame wars!
> 
> That's nice, but these kinds of discussions tend to degenerate pretty
> quickly! ;-) 

Don't think negative... Maybe the OP simply wanted a *fair* answer about 
his question...

If the discussion degenerates, maybe it depends from posters who like 
discussion degenerations better than giving clean and wise answers to 
the OP. 

(Obviously, I'm absolutely *not* referring to you as a poster who like 
discussion degenerations (!!); I'm speaking in general :)

Dan

In article <cbug7s$36k$1@bubba.nmsu.edu>, August Miller wrote:
> In 16 years of doing a few things in various flavors of C, and 43+
> years of FORTRAN, I have yet to find a C or C++ compiler which
> can evaluate (without further ado)  the equivalent of
> 
> Z3=Z1*SIN(Z2)
> 
> where all the variables are complex numbers.

#include <stdio.h>
#include <complex.h>

int main(void)
{
  double complex a = 1+I*1;
  double complex b = a+I*2;
  double complex c = a*csin(b);
  printf("c is (%f, %f)\n", creal(c), cimag(c));
}

Compile with a C99 compliant compiler. With gcc >= 3.0, you can do
something like

gcc -std=c99 -Wall -lm -o complex complex.c

Of course, since complex numbers were only addded in the C99 standard,
the damage is already done; numerical C libraries define their own
(incompatible) complex types and needed operations on these types
anyway. Not to mention that C++ has its own concept of complex via the
complex<> template class.

-- 
Janne Blomqvist

James:  That mykinds module is ingenious and quite useful in practice.  Many thanks.
	Skip Knoble

On Wed, 30 Jun 2004 06:51:32 GMT, "James Van Buskirk" <not_valid@comcast.net> wrote:

-|"Marco A. Cruz Q." <macruzq@todito.com> wrote in message
-|news:12796de5.0406291421.37dca67a@posting.google.com...
-|
-|> I learned programming with FORTRAN, and after several years of
-|> experience in programming from FORTRAN, BASIC, FOXPRO , CA-CLipper and
-|> C/C++, I may ask:  What can be done in FORTRAN that cannot be done in
-|> C/C++ or any of the previously mentioned languages? I see that C/C++
-|> has all the necessary resources to do number crunching, is really
-|> necessary to use FORTRAN?
-|
-|Oh man!  I've been writing Fortran all evening so I missed this
-|flame war up to now.  Here, have a look at some of the Fortran
-|I wrote this evening:
-|
-|! File: gen31a.f90
-|! Public domain 2004 James Van Buskirk
-|module mykinds
-|   implicit none
-|   integer, parameter :: dp = selected_real_kind(15,300)
-|   integer, parameter :: qp_preferred = selected_real_kind(30,1000)
-|   integer, parameter :: qp = (1+sign(1,qp_preferred))/2*qp_preferred+ &
-|                              (1-sign(1,qp_preferred))/2*dp
-|end module mykinds
-|
-|module tensors
-|   use mykinds
-|   implicit none
-|   interface operator(.tensor.)
-|      module procedure tensor_product
-|   end interface operator(.tensor.)
-|   interface operator(.plus.)
-|      module procedure direct_sum
-|   end interface operator(.plus.)
-|   contains
-|      function tensor_product(A1,A2)
-|         real(qp), intent(in) :: A1(:,:)
-|         real(qp), intent(in) :: A2(:,:)
-|         real(qp)
-|tensor_product(size(A1,1)*size(A2,1),size(A1,2)*size(A2,2))
-|         integer i1, i2, j1, j2
-|
-|         do i1 = 1, size(A1,1)
-|            do i2 = 1, size(A2,1)
-|               do j1 = 1, size(A1,2)
-|                  do j2 = 1, size(A2,2)
-|
-|tensor_product((i1-1)*size(A2,1)+i2,(j1-1)*size(A2,2)+j2) = &
-|                        A1(i1,j1)*A2(i2,j2)
-|                  end do
-|               end do
-|            end do
-|         end do
-|      end function tensor_product
-|
-|      function direct_sum(A1,A2)
-|         real(qp), intent(in) :: A1(:,:)
-|         real(qp), intent(in) :: A2(:,:)
-|         real(qp) direct_sum(size(A1,1)+size(A2,1),size(A1,2)+size(A2,2))
-|
-|         direct_sum = 0
-|         direct_sum(1:size(A1,1),1:size(A1,2)) = A1
-|         direct_sum(size(A1,1)+1:,size(A1,2)+1:) = A2
-|      end function direct_sum
-|
-|      function identity(n)
-|         integer, intent(in) :: n
-|         real(qp) identity(n,n)
-|         integer i
-|
-|         identity = 0
-|         do i = 1, n
-|            identity(i,i) = 1
-|         end do
-|      end function identity
-|end module tensors
-|
-|program gen31a
-|   use mykinds
-|   use tensors
-|   implicit none
-|   integer, parameter :: N = 31
-|   integer, parameter :: g = 3
-|   integer i
-|   integer crow(0:N-1), ccol(0:N-1)
-|   character(80) ifmt
-|   integer mc(N,N)
-|   integer g3, g5, g2
-|   integer j
-|   integer k
-|   real(qp) pi
-|   real(qp) theta
-|   real(qp) c(0:N-1,0:N-1)
-|   character(80) rfmt
-|   real(qp) rf2i(2,2)
-|   real(qp) f2inv(0:N-1,0:N-1)
-|   real(qp) rf5i(5,5)
-|   real(qp) f5inv(0:N-1,0:N-1)
-|   real(qp) s(0:N-1,0:N-1)
-|   character(80) pfmt
-|
-|   crow(0) = 0
-|   crow(1) = 1
-|   do i = 2, N-1
-|      crow(i) = modulo(g*crow(i-1),N)
-|   end do
-|   g3 = 10
-|   g5 = 6
-|   g2 = 15
-|   write(ifmt,'(a,i0,a)') '(',N,'(i3))'
-|   write(*,ifmt) crow
-|   crow(1:) = (/(((crow(modulo(g3*i+g5*j+g2*k,N-1)+1),i=0,2),j=0,4),k=0,1)/)
-|   ccol(0:1) = crow(0:1)
-|   ccol(2:) = crow(N-1:2:-1)
-|   ccol(1:) = crow(N-1:1:-1)
-|   write(*,ifmt) crow
-|   write(*,ifmt) ccol
-|   mc = modulo(matmul(reshape(ccol,(/N,1/)),reshape(crow,(/1,N/))),N)
-|   write(*,'()')
-|   write(*,'()') ! Work around bug in LF95 5.70d
-|   write(*,ifmt) transpose(mc)
-|   pi = 4*atan(1.0_qp)
-|   theta = 2*pi/N
-|   c = cos(theta*mc)
-|   write(rfmt,'(a,i0,a)') '(',N,'f7.3)'
-|   write(*,'()')
-|   write(*,'()') ! Work around bug in LF95 5.70d
-|   write(*,rfmt) transpose(c)
-|   rf2i = reshape((/1,1,1,-1/),shape(rf2i))
-|   rf2i = rf2i/2
-|   f2inv = identity(1).plus.((rf2i).tensor.identity((N-1)/2))
-|   c = matmul(f2inv,matmul(c,f2inv))
-|   write(*,'()')
-|   write(*,'()') ! Work around bug in LF95 5.70d
-|   write(*,rfmt) transpose(c)
-|   theta = 2*pi/5
-|   rf5i = reshape((/ &
-|     cos(0*theta), cos(0*theta), cos(0*theta), cos(0*theta), cos(0*theta), &
-|     cos(0*theta), cos(1*theta), cos(2*theta), cos(-2*theta), cos(-1*theta),
-|&
-|     sin(0*theta), sin(1*theta), sin(2*theta), sin(-2*theta), sin(-1*theta),
-|&
-|     cos(0*theta), cos(2*theta), cos(-1*theta), cos(1*theta), cos(-2*theta),
-|&
-|     sin(0*theta), sin(2*theta), sin(-1*theta), sin(1*theta),
-|sin(-2*theta)/), &
-|     shape(rf5i), order=(/2,1/))
-|   rf5i(2:4:2,:) = rf5i(2:4:2,:)/(rf5i(2,3)-rf5i(2,2))
-|   rf5i(3:5:2,:) = rf5i(3:5:2,:)/rf5i(3,2)
-|   pfmt = "(4x,'real(wp),parameter :: ',a,' = ',f0.34,'_wp')"
-|   write(*,'()')
-|   write(*,'()') ! Work around bug in LF95 5.70d
-|   write(*,pfmt) 'c1', rf5i(2,1)
-|   write(*,pfmt) 'c2', rf5i(2,2)
-|   write(*,pfmt) 's1', rf5i(3,3)
-|   forall(i=1:5) rf5i(i,:) = rf5i(i,:)/dot_product(rf5i(i,:),rf5i(i,:))
-|   rf5i = transpose(rf5i)
-|   f5inv = identity(1).plus.(rf5i.tensor.identity(3)).plus.identity((N-1)/2)
-|   c = matmul(transpose(f5inv),matmul(c,f5inv))
-|   write(*,'()')
-|   write(*,'()') ! Work around bug in LF95 5.70d
-|   write(*,rfmt) transpose(c)
-|
-|   theta = 2*pi/N
-|   s = sin(theta*mc)
-|   write(*,'()')
-|   write(*,'()') ! Work around bug in LF95 5.70d
-|   write(*,rfmt) transpose(s)
-|   s = matmul(f2inv,matmul(s,f2inv))
-|   write(*,'()')
-|   write(*,'()') ! Work around bug in LF95 5.70d
-|   write(*,rfmt) transpose(s)
-|   f5inv = identity((N+1)/2).plus.(rf5i.tensor.identity(3))
-|   s = matmul(transpose(f5inv),matmul(s,f5inv))
-|   write(*,'()')
-|   write(*,'()') ! Work around bug in LF95 5.70d
-|   write(*,rfmt) transpose(s)
-|
-|   write(*,'()')
-|   write(*,'()') ! Work around bug in LF95 5.70d
-|   write(*,pfmt) 'dc1',c(1,1)
-|   write(*,pfmt) 'dc2',c(1,2)-c(1,1)
-|   write(*,pfmt) 'dc3',c(1,3)-c(1,1)
-|   write(*,pfmt) 'dc4',c(4,7)
-|   write(*,pfmt) 'dc5',c(4,4)+c(4,7)
-|   write(*,pfmt) 'dc6',c(7,7)-c(4,7)
-|   write(*,pfmt) 'dc7',c(4,8)
-|   write(*,pfmt) 'dc8',c(4,5)+c(4,8)
-|   write(*,pfmt) 'dc9',c(7,8)-c(4,8)
-|   write(*,pfmt) 'dc10',c(4,9)
-|   write(*,pfmt) 'dc11',c(4,6)+c(4,9)
-|   write(*,pfmt) 'dc12',c(7,9)-c(4,9)
-|   write(*,pfmt) 'dc13',c(10,13)
-|   write(*,pfmt) 'dc14',c(10,10)+c(10,13)
-|   write(*,pfmt) 'dc15',c(13,13)-c(10,13)
-|   write(*,pfmt) 'dc16',c(10,14)
-|   write(*,pfmt) 'dc17',c(10,11)+c(10,14)
-|   write(*,pfmt) 'dc18',c(13,14)-c(10,14)
-|   write(*,pfmt) 'dc19',c(10,15)
-|   write(*,pfmt) 'dc20',c(10,12)+c(10,15)
-|   write(*,pfmt) 'dc21',c(13,15)-c(10,15)
-|   write(*,pfmt) 'ds1',s(16,16)
-|   write(*,pfmt) 'ds2',s(16,17)
-|   write(*,pfmt) 'ds3',s(16,18)
-|   write(*,pfmt) 'ds4',s(19,22)
-|   write(*,pfmt) 'ds5',s(19,19)+s(19,22)
-|   write(*,pfmt) 'ds6',s(22,22)-s(19,22)
-|   write(*,pfmt) 'ds7',s(19,23)
-|   write(*,pfmt) 'ds8',s(19,20)+s(19,23)
-|   write(*,pfmt) 'ds9',s(22,23)-s(19,23)
-|   write(*,pfmt) 'ds10',s(19,24)
-|   write(*,pfmt) 'ds11',s(19,21)+s(19,24)
-|   write(*,pfmt) 'ds12',s(22,24)-s(19,24)
-|   write(*,pfmt) 'ds13',s(25,28)
-|   write(*,pfmt) 'ds14',s(25,25)+s(25,28)
-|   write(*,pfmt) 'ds15',s(28,28)-s(25,28)
-|   write(*,pfmt) 'ds16',s(25,29)
-|   write(*,pfmt) 'ds17',s(25,26)+s(25,29)
-|   write(*,pfmt) 'ds18',s(28,29)-s(25,29)
-|   write(*,pfmt) 'ds19',s(25,30)
-|   write(*,pfmt) 'ds20',s(25,27)+s(25,30)
-|   write(*,pfmt) 'ds21',s(28,30)-s(25,30)
-|   pfmt = '(4x,a,z1,a,i0,a,i0,a)'
-|   do i = 1, (N-1)/2
-|      write(*,pfmt) 'xr',i,' = real(h(',crow(i),'))+real(h(',crow(i+15),'))'
-|      write(*,pfmt) 'xi',i,' =
-|aimag(h(',crow(i),'))+aimag(h(',crow(i+15),'))'
-|      write(*,pfmt) 'yr',i,' = real(h(',crow(i),'))-real(h(',crow(i+15),'))'
-|      write(*,pfmt) 'yi',i,' =
-|aimag(h(',crow(i),'))-aimag(h(',crow(i+15),'))'
-|   end do
-|   pfmt = '(4x,a,i0,a,z1,a,z1,a,z1,a,z1,a)'
-|   do i = 1, (N-1)/2
-|      write(*,pfmt) 'h(',ccol(i),') =
-|cmplx(sr',i,'+ti',i,',si',i,'-tr',i,',wp)'
-|      write(*,pfmt) 'h(',ccol(i+15),') =
-|cmplx(sr',i,'-ti',i,',si',i,'+tr',i,',wp)'
-|   end do
-|end program gen31a
-|! End of file: gen31a.f90
-|
-|Some of the features to note in the above:
-|o The code allows the compiler to fall back on double
-|  precision if quadruple precision is not available.
-|o Fortran allows easy definition of .plus. and .tensor.
-|  operators for direct sum and tensor product of matrices.
-|o Fortran has intrinsic array syntax including broadcast
-|  of scalars, FORALL, elemental sum, elemental intrinsics,
-|  and matrix multiplication.
-|
-|I think it would be rather tricky to emulate these features
-|in a small self-contained C++ program, and as a bonus it
-|takes one or more orders of magnitude less time to learn
-|Fortran than it does do learn C++.  If what one is trying
-|to achieve is a good match for Fortran as in the program
-|above, it makes sense to me to apply Fortran to the problem.


   Herman D. (Skip) Knoble, Research Associate
   (a computing professional for 38 years)
   Email: SkipKnobleLESS at SPAMpsu dot edu
   Web: http://www.personal.psu.edu/hdk
   Penn State Information Technology Services
    Academic Services and Emerging Technologies
     Graduate Education and Research Services
   Penn State University
     214C Computer Building
     University Park, PA 16802-21013
   Phone:+1 814 865-0818   Fax:+1 814 863-7049

August Miller wrote:


> In 16 years of doing a few things in various flavors of C, and 43+
> years of FORTRAN, I have yet to find a C or C++ compiler which
> can evaluate (without further ado)  the equivalent of

> Z3=Z1*SIN(Z2)

C99 has complex variables, and presumably the functions
to go with it.  I don't know that any compilers are
available yet.

-- glen

Marco A. Cruz Q. wrote:
> Hello everybody!
> 
> I learned programming with FORTRAN, and after several years of
> experience in programming from FORTRAN, BASIC, FOXPRO , CA-CLipper and
> C/C++, I may ask:  What can be done in FORTRAN that cannot be done in
> C/C++ or any of the previously mentioned languages? I see that C/C++
> has all the necessary resources to do number crunching, is really
> necessary to use FORTRAN?
> 
> Thanks in advance
> 
> Marco A. Cruz Quevedo

I am a newbie in the fortran world, so excuse me if I am wrong. I 
presume, most of the things "can be achieved" in C or C++, but in 
Fortran 90 "they are there".

1) When it comes to number crunching I find Fortran90 style more 
intuitive where you can have elemental functions operating on arrays.

2) Flexible array limits. I can have array(0:9), array(1:10) or 
array(10:19) depending whichever I find intuitive.

3) functions like reshape saved me a lot of time while coding.

4) dynamic allocation of multi-dimensional arrays is a breeze in fortran 
90. Imagine dynamically allocating array(2:12, 5:21, 6:13, 9:25). 
Compare the codes for allocating and deallocating this kind of array in 
C/C++ and in fortran 90.

5) run time checking of exceeding array bounds is possible with most of 
the fortran compilers. I could not find such an option for gcc or g++.

6) There are lots of ways to pass arrays to a subroutine/functions. 
Using assumed-shape arrays, the shape of arrays can be computed on the fly.

There are many more....

In my opinion most of the things can be done by most of the languages, 
but the important question is how "easily / intuitively" can it be done?

raju

August Miller <amiller@dirac.nmsu.edu> wrote in message news:<cbug7s$36k$1@bubba.nmsu.edu>...
> As they say, FWIW:
> 
> In 16 years of doing a few things in various flavors of C, and 43+
> years of FORTRAN, I have yet to find a C or C++ compiler which
> can evaluate (without further ado)  the equivalent of
> 
> Z3=Z1*SIN(Z2)
> 
> where all the variables are complex numbers.

Finally, a good answer!

I will take this as a challenge to make it in C/C++ besides FORTRAN.
The question is coming from the fact that the Fortran I learned was
Fortran IV and checking in last days about the evolution of this
programming language, I found that the language is being added
object-oriented features, what for, if there is C++? Is not it enough?

Regards

Marco A. Cruz Quevedo

August Miller wrote:

> As they say, FWIW:
> 
> In 16 years of doing a few things in various flavors of C, 
> and 43+ years of FORTRAN, I have yet to find a C or C++ compiler 
> which can evaluate (without further ado) the equivalent of
> 
> Z3=Z1*SIN(Z2)
> 
> where all the variables are complex numbers.

         > cat main.c
         #include <stdio.h>
         #include <complex.h>

         int main(int argc, char* argv[]) {
           double complex        z1 = +1.0 + 1.0*I;
           double complex        z2 = +1.0 - 1.0*I;
           double complex        z3 = z1*csin(z2);
           fprintf(stdout, "(%lf, %lf) = z1\n", creal(z1), cimag(z1));
           fprintf(stdout, "(%lf, %lf) = z2\n", creal(z2), cimag(z2));
           fprintf(stdout, "(%lf, %lf) = z3\n", creal(z3), cimag(z3));
           return 0;
           }

         > gcc -Wall -std=c99 -pedantic -o main main.c -lm
         main.c:5:49: warning: imaginary constants are a GCC extension
         main.c:6:49: warning: imaginary constants are a GCC extension
         > ./main
         (1.000000, 1.000000) = z1
         (1.000000, -1.000000) = z2
         (1.933421, 0.663494) = z3

Now you've seen one.

macruzq@todito.com (Marco A. Cruz Q.) writes:

> The question is coming from the fact that the Fortran I learned was
> Fortran IV

If the last Fortran you learned was Fortran IV, then you really don't
know much at all about Fortran today.  I don't mean that in an
insulting sense.  (My mother also doesn't know much at all about Fortran
today and I don't think less of her for it).  I mean it purely as
a point of fact.  Just glancing at textbook descriptions of the
changes isn't enough to fully understand them and their implications;
the changes are far too fundamental for that.

I assure you that if Fortran today meant Fortran IV (or even Fortran
77), then I for one would no longer be using it.  So yes, it makes
quite a big difference.

> I found that the language is being added
> object-oriented features, what for, if there is C++? Is not it enough?

No, it isn't.  It certainly isn't enough for me.  As I mentioned
beefore, my productivity on C++ is approximately zero.  This is
not likely to change.

If C++ is "enough" for you, then by all means use it.  I don't know
why you seem to be begging for other people to talk you out of it.
Ain't going to happen.  I'm quite happy for you to use whatever you
find best for your purposes.

No, I'm not going to elaborate on why C++ isn't for me.  If you really
want to peruse such flame wars, then go find them in google.  It
shouldn't be hard as there are plenty of them.  Pretty much *ANY*
question along the line of "why doesn't everyone else make the
same choices as I do?" is fundamentally flame bait.  Just accept
the fact that different choices are better for different people.

I probably don't share the same religion as you, and I'm not going to
argue about that either (or even mention what mine is).  Why do other
people insist on having religions other than mine?  Isn't mine enough?

If you ask in an unbiased way, then I'd have at least some temptation
to elaborate, though the subject is prone to generate flames,
even when it starts off objectively.  But "why shouldn't I use XXX?"
is a prejudicial way of asking a question in the first place.
That's what I tried to point out by using the same phrasing inverted
or for completely different subjects.

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

"E. Robert Tisdale" wrote:
>
> > Is it really necessary to use FORTRAN?
> No.

Right on ET, especially if taxpayers money's no object! How's that multi
million Fortran -> C++ conversion (as described by Van Snyder) fiasco
going??

Kamaraju Kusumanchi <kk288@cornell.edu> wrote:
> Marco A. Cruz Q. wrote:
>> Hello everybody!
>> 
>> I learned programming with FORTRAN, and after several years of
>> experience in programming from FORTRAN, BASIC, FOXPRO , CA-CLipper and
>> C/C++, I may ask:  What can be done in FORTRAN that cannot be done in
>> C/C++ or any of the previously mentioned languages? I see that C/C++
>> has all the necessary resources to do number crunching, is really
>> necessary to use FORTRAN?
>> 
>> Thanks in advance
>> 
>> Marco A. Cruz Quevedo
> 
> I am a newbie in the fortran world, so excuse me if I am wrong. I 
> presume, most of the things "can be achieved" in C or C++, but in 
> Fortran 90 "they are there".

To me, the most important features of Fortran 95 are the things that
you CANNOT do in it, that you can in C++.

For instance, ponder the difference between assignment operators,
copy constructors and constructors.

see things happen almost, but not QUITE right, with liberal use of
"&".  

Puzzle your friends with type definitions.

Feel bamboozled at the error messages involving names and types
you've never heard of when using the STL.

Wonder about the meaning of 'const' and have to propagate
'const'ness all over the place, instead of the boringly obvious
intent([in,out,inout]).

write magnificent literature like this:

/// One of the @link s20_3_6_binder binder functors@endlink.
template <class _Operation>
class binder2nd
  : public unary_function<typename _Operation::first_argument_type,
                          typename _Operation::result_type> {
protected:
  _Operation op;
  typename _Operation::second_argument_type value;
public:
  binder2nd(const _Operation& __x,
            const typename _Operation::second_argument_type& __y)
      : op(__x), value(__y) {}
  typename _Operation::result_type
  operator()(const typename _Operation::first_argument_type& __x) const {
    return op(__x, value);
  }
#ifdef _GLIBCPP_RESOLVE_LIB_DEFECTS
  //109.  Missing binders for non-const sequence elements
  typename _Operation::result_type
  operator()(typename _Operation::first_argument_type& __x) const {
    return op(__x, value);
  }
#endif
};
 


> In my opinion most of the things can be done by most of the languages, 
> but the important question is how "easily / intuitively" can it be done?

Often in C++, almost irredeemably buggy and impenetrable programs are dense
in the set of correct programs.

> raju

And yes, I have used it for my own research, including quite recently.
With the standard library it really IS better than it used to be, but
I'm quite aware of the problems. 

"E. Robert Tisdale" wrote:
> 
>            double complex        z3 = z1*csin(z2);
>            fprintf(stdout, "(%lf, %lf) = z1\n", creal(z1), cimag(z1));
> 
> Now you've seen one.

And mortified to the bones he's sprinting away so fast M. Green couldn't
catch up with him...

	complex z1,z2,z3
	z3 = z1*sin(z2)
	print*, z1,z2,z3

Bloating the sw, eventually someone has to read it, is an economic
consideration that matters in some places.

"Jan Vorbr�ggen" <jvorbrueggen-not@mediasec.de> wrote in message
news:2kfau8F1ivveU1@uni-berlin.de...
> > the Field Medal (I guess it's some kind of farmer's prize)
>
> ROTFL - that's a good one!

You witless dodo. Faux Medals like the Fields are unscientific voodoo
charms, favored by intellectual gypsies and their groupies. All recipients
ought to be dolled up and made to ride in the marshal's float at the
Toronto Gay Pride Day Parade

Most real scientists could care less about the complexity of the halting
problem. Neither does nature. It's a nonproblem whose resolution is of no
significant consequence.

-- 
You're Welcome,
Gerry T.
______
"Ah, Klinger, my constant reminder that Darwin was right!." -- Maj Charles
Winchester III, the 4077th M*A*S*H

macruzq@todito.com (Marco A. Cruz Q.) wrote in message news:<12796de5.0406291421.37dca67a@posting.google.com>...
> Hello everybody!
> 
> I learned programming with FORTRAN, and after several years of
> experience in programming from FORTRAN, BASIC, FOXPRO , CA-CLipper and
> C/C++, I may ask:  What can be done in FORTRAN that cannot be done in
> C/C++ or any of the previously mentioned languages? I see that C/C++
> has all the necessary resources to do number crunching, is really
> necessary to use FORTRAN?

Having been programming with C++ for some 10 years, I started to do
some development in Fortran a couple of months ago. From what I
managed to learn in Fortran so far, there are the things I like about
it:

1) Array manipulation: whole-array assignments, array sections,
allocation/deallocation of multidimensional arrays, inquiry functions,
etc. Of course, you can either write your own array classes in C++ and
do the same things, but it's an extra work, or you can use some
existing libraries, but then you have to cope with incompatible
interfaces of different libraries, portability, etc.

2) Implied DO loops, like in the WRITE statement. Pretty handy in many
cases;
3) Masked assignments; FORALL statement.

Things that I used to use in C++ and I'm missing them in Fortran:

1) OOP; there are some rudimentary means to imitate OOP in Fortran90,
but if you call it an OOP, then you as well might call C
object-oriented, too;
2) Templates; Fortran INTERFACE statement is not nearly as flexible
and convenient as function templates in C++; and there are no (AFAIK)
template library like STL;
3)  I/O handling less flexible and convenient than <iostream>
operations.

Dr Chaos <mbkennelSPAMBEGONE@NOSPAMyahoo.com> wrote in message news:<slrnce6eji.teb.mbkennelSPAMBEGONE@lyapunov.ucsd.edu>...
 
> To me, the most important features of Fortran 95 are the things that
> you CANNOT do in it, that you can in C++.

Besides the examples you gave, I am glad Fortran prevents me from
changing the DO loop variable within the body of a loop, which can
easily lead to bugs. I cannot write

do i=1,10
   ! some code
   i = i*2
end do

If I REALLY want this, I can write a DO loop with no loop variable and
an EXIT statement, but I rarely do.

When I see examples of unsafe code (enabling buffer overruns for
example) the sample code is almost always written in C, and it does
not look OBVIOUSLY wrong to me. This suggests that C places a higher
burden on the programmer than other languages to write safe code. I
think both Java (which does not have pointers) and the "managed code"
of .NET (and the C# language) were partly designed to avoid the
security risks of C.

Rodney Bates discussed the security problems of C in an article
"Buffer Overrun Madness" in the May 2004 issue of ACM Queue. Below is
an excerpt -- the full article is at
http://www.acmqueue.org/modules.php?name=Content&pa=showpage&pid=147 .

"Even when programmers use them, C and C++ array types can carry only
static bounds. Many arrays in programs need to have dynamic size: most
frequently, array formal parameters. Here, the actual parameters are
often static-size, but the formals need to be dynamically sized to
accept different actuals. For these cases, the type system of C/C++
offers only array types of unknown size. So even if the programmer
declares using an array type, the bounds are lost.

Between the language's ignoring array types, the lack of dynamic-size
array types that carry their bounds, and programmers' habits of not
using array types anyway, there is no way to redesign the type system
to support array bounds checking without requiring significant
recoding of virtually everything.

You might imagine an automatic code conversion program to go along
with a repaired type system. It would have to be very sophisticated to
distinguish among pointers used to access arrays, pass parameters by
reference and as legitimate pointers to linked data structures. It
would have to do whole-program analysis, which in turn is especially
difficult in C and C++, because their lack of linguistic recognition
of separate compilation makes it very difficult even to locate all the
relevant source code.

In languages with well-designed type systems, array types have to be
used to access arrays. These types carry their bounds as part of the
type if the bounds are static, or as part of the value if not. Then
they can generate runtime bounds checks on array element accesses,
where needed. Programmers can still create buffer overrun bugs, but
the consequences are far less serious.

The code itself can be changed to prevent buffer overruns, even in
weakly typed languages. That is exactly what is happening, bug by bug,
to close the security holes. But the endless flood of reported buffer
overrun vulnerabilities shows that the number of holes is enormous.
What portion can be attributed directly to a bad type system and what
portion to bad programmer habits engendered thereby is anybody's
guess. So far, the rate of new discoveries of such vulnerabilities
shows no sign of diminishing.

Why do so many cling to languages that are 45 years behind the state
of the programming language art? As a programming languages
specialist, I have had decades of discussions about this with both
practitioners and academicians. Most of the reasons boil down to,
"It's what everybody else is doing." There are some exceptions�valid
points, though easily answered. When software developers choose
languages on their merits, a lot of ugly problems will become simple
problems. But don't worry that it might make programmers redundant.
The space of problems that cannot be solved by any known language
technology will always be larger than the space of those that can, and
far bigger than our collective capacity."

beliavsky@aol.com wrote:

> When I see examples of unsafe code (enabling buffer overruns for
> example) the sample code is almost always written in C, and it does
> not look OBVIOUSLY wrong to me. This suggests that C places a higher
> burden on the programmer than other languages to write safe code. I
> think both Java (which does not have pointers) and the "managed code"
> of .NET (and the C# language) were partly designed to avoid the
> security risks of C.

Without meaning to gloat too much, I always find it amusing that gets() 
is _still_ part of ISO C. It seems that C doesn't just make it _easy_ to 
have buffer overruns - the language definition *specifies* them.

I also like Henry Baker's post to comp.risks:

-----

I'm no fan of lawyers or litigation, but it's high time that someone 
defined "buffer overflow" as being equal to "gross criminal negligence".
.....
I have been told that one of the reasons for the longevity of the Roman 
bridges is that their designers had to stand under them when they were 
first used.  It may be time to put a similar discipline into the 
software field.

<http://catless.ncl.ac.uk/Risks/21.84.html#subj10.1>

------

There are things I'd like to see Fortran take from C++ at least - the 
basic idea of the STL, even if the implementation is somewhat different. 
But array handling is _the_ reason I stick to Fortran.

Richard

Richard Maine <nospam@see.signature> wrote in message news:<m1vfhayoqq.fsf@macfortran.local>...

<SNIP>

> My personal productivity in Fortran is approximately
> a factor of 10 better than in C.  And in C++, my productivity is
> essentially zero.  With other people, the numbers will be different...
> and fo rother people teh best choices are different.

(I am reluctant to debate a much more knowledgable programmer on the
subject of his own productivity, but here goes ...)

Since C++ is almost a superset of C, saying that one is much more
productive in C than C++ makes as much sense to me as a claim of much
greater productivity in Fortran 77 than 95.

C++ can and often is used as a better C, and one can write in a way
that is closer to Fortran. For example,

(1) Constants can be declared, similar to Fortran PARAMETERs
(2) Single-line comments with "//" are closer to the Fortran "!" than
the C comment.
(3) The C++ vector (and valarray), like a 1-D Fortran array, knows it
own size. In C++ one can develop matrix classes with some of the
functionality of Fortran multidimensional arrays.
(4) Passing function arguments by reference (especially arrays and
objects) seems more natural to me than using pointers.

Even if one does not write object-oriented programs, I think C++ (at
least a subset of it) is a more natural language for a Fortranner than
C. One is not forced to learn or use all of its features, unless they
are used in someone else's code that you are trying to modify.

Btw, has anyone designed a subset C++ compiler analogous to the F
subset of Fortran, keeping only the "safe" and "modern" features
(terms subject to interpreation)?

beliavsky@aol.com wrote:
> Richard Maine <nospam@see.signature> wrote in message
> news:<m1vfhayoqq.fsf@macfortran.local>...
>
> <SNIP>
>
>> My personal productivity in Fortran is approximately
>> a factor of 10 better than in C.  And in C++, my productivity is
>> essentially zero.  With other people, the numbers will be different...
>> and fo rother people teh best choices are different.
>
> (I am reluctant to debate a much more knowledgable programmer on the
> subject of his own productivity, but here goes ...)
>
> Since C++ is almost a superset of C, saying that one is much more
> productive in C than C++ makes as much sense to me as a claim of much
> greater productivity in Fortran 77 than 95.

That doesn't confuse me.  When programming in an extended
language you invariably end up using most (if not all) of the
new features regularly.  Unless you have dictatorial control
over your programming environment and/or are the only
programmer on any of your projects, you probably don't
even have much choice.  If the extensions to the base language
are poorly designed, arcane, and/or take long learning curves to
use well, I have no doubt that the productivity of very many
(if not most) programmers will decrease when using the larger
language - at least at first.  I believe it to be a permanent
reduction in productivity in most cases where C++ in concerned
(it seems that the learning curve for C++ is longer than the
portion of most people's careers that they spend doing actual
coding).

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

Richard Edgar wrote:
> ...
> Without meaning to gloat too much, I always find it amusing that gets()
> is _still_ part of ISO C. It seems that C doesn't just make it _easy_ to
> have buffer overruns - the language definition *specifies* them.

Well Fortran proponents can't claim too much of the moral high ground.

The 'default' implicit typing is horribly bug-prone and should have been
considered deprecated years ago.  So far The Committee has collectively
placed their heads firmly in the sand on addressing the issue.  (Note that
C89 had issues in this area too, but to their credit, they have fixed it
in C99.)

Fortrans error detection capabilities (e.g., STAT= and the like) have
gradually gotten better over the years. But this has been a piecewise
approach.  Fortran does not, and F2003 still won't, have a real structured
exception handling (e.g., try/throw/catch) functionality.  This is a fairly
large hole in Fortran (compared to C++/Java/Python/ADA/PL1/etc.)

> I also like Henry Baker's post to comp.risks:

I always enjoy his articles.  Thanks.

Walt
-...-
Walt Spector
(w6ws at earthlink dot net)

Walter Spector wrote:

> The 'default' implicit typing is horribly bug-prone and should have been
> considered deprecated years ago.  So far The Committee has collectively
> placed their heads firmly in the sand on addressing the issue.

I agree that implicit typing is a rather nasty thing, but I think that's 
  a bit harsh on the (present) committee. Remember that IMPLICIT NONE 
only put in an appearance in F90, so expecting it to be the default from 
then is a bit extreme. Perhaps it should have been considered for F2k[n] 
(would a committee member like to comment on this?).

Richard

Personnally, I found syntax of Fortran is superior ;-)
Also, writing a good program in Fortran is easy.
But with C/C++ you have interest to find programmer with good experience.

"Richard Edgar" <rge21@astro.su.se> wrote in message
news:cc10s9$4fs$1@news.su.se...
> beliavsky@aol.com wrote:
>
> > When I see examples of unsafe code (enabling buffer overruns for
> > example) the sample code is almost always written in C, and it does
> > not look OBVIOUSLY wrong to me. This suggests that C places a higher
> > burden on the programmer than other languages to write safe code. I
> > think both Java (which does not have pointers) and the "managed code"
> > of .NET (and the C# language) were partly designed to avoid the
> > security risks of C.
>
> Without meaning to gloat too much, I always find it amusing that gets()
> is _still_ part of ISO C. It seems that C doesn't just make it _easy_ to
> have buffer overruns - the language definition *specifies* them.
>
> I also like Henry Baker's post to comp.risks:
>
> -----
>
> I'm no fan of lawyers or litigation, but it's high time that someone
> defined "buffer overflow" as being equal to "gross criminal negligence".
> ....
> I have been told that one of the reasons for the longevity of the Roman
> bridges is that their designers had to stand under them when they were
> first used.  It may be time to put a similar discipline into the
> software field.
>
> <http://catless.ncl.ac.uk/Risks/21.84.html#subj10.1>
>
> ------
>
> There are things I'd like to see Fortran take from C++ at least - the
> basic idea of the STL, even if the implementation is somewhat different.
> But array handling is _the_ reason I stick to Fortran.
>
> Richard

Richard Edgar <rge21@astro.su.se> writes:

> Remember that IMPLICIT
> NONE only put in an appearance in F90, so expecting it to be the
> default from then is a bit extreme. Perhaps it should have been
> considered for F2k[n] (would a committee member like to comment on
> this?).

In my formal comments on f90 (before I was on the committee), I
suggested making implicit none the defaulu fro free source form.
I figured that wouldn't break existing standard-conforming codes
because all existing standard-conforming codes used fixed source
form.  (It wouldn't have been hard to have source form converter
programs add in an implicit statement).

Though some of my comments were accepted, that one wasn't.
I figure we missed a golden opportunity as a result.  If we change
the default now, then it would invalidate existing code, which
makes it a pretty big deal.  I seriously doubt that would fly.
Perhaps the standard could require compilers to have both
options (i.e. require that there be something like a compiler
switch separate from  the code).  The standard has generally
steered clear of requirements like that, but I see no fundamental
reason why that couldn't change; whether it actually will change
is not something I am willing to place oddds on either way.

It does seem far more plausible to me that a new standard might
demand the equivalent of a compiler switch than that a new
standard would invalidate that much existing code.  Just my
personal guess.  Of course, we all know that even if the standard
did make such a change, actual compilers would make it a
switch (many do already), so the practical effect might be
little different, but I still think that it would look to bad
on paper (and thus in legal matters) to have the standard
officially declare such code invalid; the "wink.  It is ok
with real compilers anyway" wouldn't be good enough.


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

Richard Edgar wrote:
> Walter Spector wrote:
> 
>> The 'default' implicit typing is horribly bug-prone and should have been
>> considered deprecated years ago.  So far The Committee has collectively
>> placed their heads firmly in the sand on addressing the issue.
> 
> 
> I agree that implicit typing is a rather nasty thing, but I think that's 
>  a bit harsh on the (present) committee. Remember that IMPLICIT NONE 
> only put in an appearance in F90, so expecting it to be the default from 
> then is a bit extreme. Perhaps it should have been considered for F2k[n] 
> (would a committee member like to comment on this?).
> 
> Richard
Speaking for nobody but myself, there're a few reasons, in
no particular order.

1)  Nobody has volunteered to do the work and figure out
how to do it.

2)  The compiler vendors haven't come to J3 and said that
their users are livid about this lack.

3)  There doesn't seem to be a way to do it and still keep
the old codes working.  When PAUSE was "removed" from the
language, all the vendors had to do was add a "non-standard"
warning message to their existing PAUSE support.  The old
programs kept on working, with an occasional PAUSE, new
programs worked without PAUSE.  How do you do an implicit
IMPLICIT NONE (however you spell it)?  If you just do it,
then old programs won't compile.  If the vendors add a
command line switch (-/no_implicit_IMPLICIT_NONE, perhaps)
then new codes won't get the benefit unless the programmer
is careful about keeping his coding styles separate.
Most people I know search exactly once for a set of
command line parameters that work and then use them for
the rest of their lives or until they stop working.  So,
they'll quickly lose the benefit.

4)  Having to declare variables in small throwaway codes
or for temporaries when debugging is a pain in the
butt.  People who want the pain^H^H^H^H benefit can easily
put in IMPLICIT NONE.

None of that means that implicit type declaration is a good
feature, just that it's hard to change.

Dick Hendrickson

Richard Maine wrote:
> 
> Richard Edgar <rge21@astro.su.se> writes:
> 
> > Remember that IMPLICIT
> > NONE only put in an appearance in F90, so expecting it to be the
> > default from then is a bit extreme. Perhaps it should have been
> > considered for F2k[n] (would a committee member like to comment on
> > this?).
> 
> In my formal comments on f90 (before I was on the committee), I
> suggested making implicit none the defaulu fro free source form.
> I figured that wouldn't break existing standard-conforming codes
> because all existing standard-conforming codes used fixed source
> form.  (It wouldn't have been hard to have source form converter
> programs add in an implicit statement).
> 
> Though some of my comments were accepted, that one wasn't.
> I figure we missed a golden opportunity as a result.  If we change
> the default now, then it would invalidate existing code, which
> makes it a pretty big deal.  I seriously doubt that would fly.
> Perhaps the standard could require compilers to have both
> options (i.e. require that there be something like a compiler
> switch separate from  the code).  The standard has generally
> steered clear of requirements like that, but I see no fundamental
> reason why that couldn't change; whether it actually will change
> is not something I am willing to place oddds on either way.
> 
> It does seem far more plausible to me that a new standard might
> demand the equivalent of a compiler switch than that a new
> standard would invalidate that much existing code.  

I bet no vendors would seriously object to a switch for backward
compatibility.

> Just my
> personal guess.  Of course, we all know that even if the standard
> did make such a change, actual compilers would make it a
> switch (many do already), so the practical effect might be
> little different, but I still think that it would look to bad
> on paper (and thus in legal matters) to have the standard
> officially declare such code invalid; the "wink.  It is ok
> with real compilers anyway" wouldn't be good enough.
> 
> --
> 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


-- 

Gary Scott
mailto:garyscott@ev1.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

Why are there two?  God only knows.

Democracy is two wolves and a sheep, voting on what to eat for dinner...
Liberty is a well armed sheep contesting the vote. - Thomas Jefferson

Gary L. Scott wrote:
> Richard Maine wrote:
....
>> It does seem far more plausible to me that a new standard might
>> demand the equivalent of a compiler switch than that a new
>> standard would invalidate that much existing code.
>
> I bet no vendors would seriously object to a switch for backward
> compatibility.


Actually, I would bet that most vendors would object to
making non-standard behavior the default.

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

Marco A. Cruz Q. <macruzq@todito.com> wrote:

> The question is coming from the fact that the Fortran I learned was
> Fortran IV and checking in last days about the evolution of this
> programming language, I found that the language is being added
> object-oriented features, what for, if there is C++? Is not it enough?

Depends. A little bit of object oriented is enough to do alot of what
I regard as the "good stuff" without the onerous requirements that go 
with a fully object oriented language like Java (which I find a pain).

I can write modules which hide away all the ugly stuff that users
of the code don't in general need to know about, and provide nice
simple interfaces. Lovely.

I used to write alot of perl scripts for quick little jobs, but 
since I have accumulated a critical mass of useful modules I find 
I now do alot of these tasks with fortran programs.

I was hacking some existing C code the other day and wanted the
equivalent of the optional arguments that are available in Fortran.
Oh boy! Doing a search on "optional arguments" in comp.lang.c was
not pretty. Fortran for me. 

Here is an example of how clean (IMO) fortran 90 can be. This is a
program for calculating some summary statistics of marresearch image 
plate data from X-ray diffraction studies. Typically the images are
2000x2000 pixels:

program marstats

  !! Reports some stats on a mar345 file

  use iso_varying_string
  use cmdline_arguments, only: have_args, num_args, next_arg, get_options, option_exists, bad_options
  use string_functions, only: join, real
  use file_functions, only: stderr, stdout
  use mar_class, only: new, mar_object, size, get_data, destroy
  use sort_functions, only: sort, unique, operator(.sort.)
  use variable_array, only: push

  implicit none

  integer :: nx, ny, npixels, nunique, error, ivalue, i

  character(len=500) :: fname, buffer

  integer, allocatable :: data(:,:), mode_counts(:)
  integer, pointer     :: data_1d(:), unique_values(:)

  logical :: domin = .FALSE., domax = .FALSE.
  logical :: domean = .FALSE., domedian = .FALSE., domode = .FALSE.

  type (varying_string) :: myoptions(6)

  type (mar_object) :: mar

  ! These are our accepted command line options (see subroutine usage for
  ! an explanation)

  myoptions(1) = 'help'
  myoptions(2) = 'min'
  myoptions(3) = 'max'
  myoptions(4) = 'mean'
  myoptions(5) = 'median'
  myoptions(6) = 'mode'

  ! This call parses the command line arguments for command line options
  call get_options(myoptions, error)

  ! Check we weren't passed duff options -- spit the dummy if we were
  if (error > 0) then
     write(stderr,*) 'ERROR! Unknown options: ',join(bad_options()," ")
     call usage
     STOP
  end if

  ! Check if we just want to print the usage
  if (option_exists('help')) then
     call usage
     STOP
  end if

  ! Check what metrics we want to report
  domin    = option_exists('min')
  domax    = option_exists('max')
  domean   = option_exists('mean')
  domedian = option_exists('median')
  domode   = option_exists('mode')

  ! Our default is to report just median and mode if no command line 
  ! options were used to specify what is required
  if (.NOT. any((/domin, domax, domedian, domean, domode/))) then
     domedian = .TRUE.
     domode   = .TRUE.
  end if

  if (num_args() < 1) then
     write(stderr,*) 'ERROR! Must supply mar data file(s) as command-line arguments'
     call usage
     STOP
  end if

  do while (have_args())

     ! The mar files are on the command line
     fname = next_arg()
     write(stdout,'(A,A)',advance='no') trim(fname), " : "

     call new(trim(fname),mar)
     
     nx = size(mar)
     ny = size(mar)
     
     ! Allocate the space required for the data
     allocate(data(nx,ny))

     data = get_data(mar)

     npixels = count(data /= 0)

     call destroy(mar)

     if (domin)  write(stdout,'("min = ",I0," ")',advance='no') minval(data,mask=(data/=0))
     if (domax)  write(stdout,'("max = ",I0," ")',advance='no') maxval(data)
     if (domean) write(stdout,'("mean = ",F0.2," ")',advance='no') mean(data,npixels)

     if (domedian .OR. domode) then

        allocate(data_1d(npixels))

        ! Make a one dimensional version of the data
        data_1d = pack(data,(data /= 0))

        ! Sort the pixel values
        call sort(data_1d)

        ! Need to put in proper check for odd/even npixels
        if (domedian) write(stdout,'("median = ",I0," ")',advance='no') data_1d(npixels/2)

        if (domode) then

           ! Make a list of unique values
           nunique = push(unique_values,unique(data_1d))

           allocate(mode_counts(nunique))
           mode_counts = 0

           ivalue = 1
           do i = 1, npixels
              if (data_1d(i) /= unique_values(ivalue)) ivalue = ivalue + 1 
              mode_counts(ivalue) = mode_counts(ivalue) + 1 
           end do

           unique_values = unique_values(.sort. mode_counts)
           write(stdout,'("mode = ",I0," ")',advance='no') unique_values(nunique)

           deallocate(mode_counts)
           nullify(unique_values)

        end if

        deallocate(data_1d)

     end if
     
     deallocate(data)

     write(stdout,*)

  end do

  contains
    
    subroutine usage

      write(stderr,*)
      write(stderr,*) 'Usage: marstats --help --min --max --mean --median --mode marfile(s)'
      write(stderr,*)
      write(stderr,*) '  --help   - print this message.'
      write(stderr,*) '  --min    - calculate minimum'
      write(stderr,*) '  --min    - calculate maximum'
      write(stderr,*) '  --mean   - calculate mean'
      write(stderr,*) '  --median - calculate median'
      write(stderr,*) '  --mode   - calculate mode'
      write(stderr,*)
      write(stderr,*) ' By default, median and mode are output. Specifying an other statistic'
      write(stderr,*) ' will output *only* those statistics'
      write(stderr,*)

    end subroutine usage

    real function mean (array, n)
      
      integer, intent(in) :: array(:,:), n

      integer(kind=8) :: total

      total = 0
      do i = 1, size(array,2)
         total = total + sum(array(:,i))
         ! print *,i,total
      end do
      mean = real(total, 8) / n

    end function mean

end program marstats

-- 
Remove famous (dead) Italian author plus full-stop to send me email (don't 
blame me about the spelling of Alighieri -- it is the sysadmin's fault!)

Dick Hendrickson wrote:
> ...
> 1)  Nobody has volunteered to do the work and figure out
> how to do it.

It is pretty easy to depricate it.  Richard just highlights the
single sentance (e.g., in �5.3 of the F2003 draft, page 93 lines
5 and 6) with his mouse, and changes the font.  Then add a note
in the appendix on depricated features.

> 2)  The compiler vendors haven't come to J3 and said that
> their users are livid about this lack.

I wouldn't expect them to.

> 3)  There doesn't seem to be a way to do it and still keep
> the old codes working.  When PAUSE was "removed" from the
> language, all the vendors had to do was add a "non-standard"
> warning message to their existing PAUSE support.

Note that I said "depricate", NOT "remove".  Big difference.

>  The old
> programs kept on working, with an occasional PAUSE, new
> programs worked without PAUSE.  How do you do an implicit
> IMPLICIT NONE (however you spell it)?

Same way many C99 compilers do it and your PAUSE example did it.
Nag the user with a caution and keep compiling.  If a user gets
tired of the nagging, he can either:

a.) Add the necessary type declarations (best),

b.) Add IMPLICT REAL(A-H,O-Z), INTEGER(I-N) in each program unit.
(I do not advocate deprication of the IMPLICIT statement from the
Standard),

c.) Flip a compiler switch to shut it up (worst)

Considering modern text processing tools, option B is quite feasible
for even the largest applications.  Again, I do not advocate the
deprication of the IMPLICIT statement or capability - just the "default"
action.

> 4)  Having to declare variables in small throwaway codes
> or for temporaries when debugging is a pain in the
> butt.  People who want the pain^H^H^H^H benefit can easily
> put in IMPLICIT NONE.

Seems like everytime I write one of those "small throwaway"
programs, and say to myself "just this once I don't need to type
everything", I get burned anyway...

Walt
-...-
Walt Spector
(w6ws at earthlink dot net)

> In my formal comments on f90 (before I was on the committee), I
> suggested making implicit none the defaulu fro free source form.
> I figured that wouldn't break existing standard-conforming codes
> because all existing standard-conforming codes used fixed source
> form.  [...]
> Though some of my comments were accepted, that one wasn't.
> I figure we missed a golden opportunity as a result.

Quite agreed.

I've often noted that the argument "we can do <whatever> now, but we will
not reasonably get a chance to do <whatever> in the future" doesn't seem very
convincing to most people. I don't really understand that kind of behaviour...
oh well. It's somewhat similar to marriage, when the attending crowd is told
that any objections should be spoken out then, or one should remain forever
silent (I only know the proper wording in German, not in English) 8-)...

	Jan

 > Fortran does not, and F2003 still won't, have a real structured
> exception handling (e.g., try/throw/catch) functionality.  This is a fairly
> large hole in Fortran (compared to C++/Java/Python/ADA/PL1/etc.)

I have my doubts on the actual, day-to-day usefulness of exception handling
- even though I was raised on VMS, which has exceptional facilities in this
regard that I have used extensively. Things like better tracebacks when errors
are detected - yes, that is ubiquitously useful, but how many compilers except 
those derived from the DEC compilers have that? That shows to me that people
don't really expect such support.

The problem with exception handling is that you need to think through what
_could_ happen at any place in the code and in time, and those considerations
better be exhaustive, and _decide_ what to do in all or at least a large
fraction of those cases. That is hard work. In addition, you are usually
working in an environment where exceptional behaviour is only loosely
specified or not specified at all: Thus, you cannot perform the above thinking
in such cases for lack of information. Again, as a comparison in VMS at least
the documentation (and in some cases the code) was changed when exceptional
conditions in the code and the documentation did not match.

When these facilites are used, in many case I have seen them used just to
improve error reporting. But that is a quality of implementation issue: so
insist that your compiler/OS/application designer provides you with such
information in an easy to use way.

	Jan

Jan Vorbr�ggen wrote:
> 

> 
> When these facilites are used, in many case I have seen them used just to
> improve error reporting. But that is a quality of implementation issue: so
> insist that your compiler/OS/application designer provides you with such
> information in an easy to use way.
> 
>         Jan

In many cases they are used _just_ for error reporting or capturing
errors:

For instance, in Java opening a file for reading that does not yet exist
is an exception, so you have to catch that. But it is rather one of
those
things you _have_ to expect to happen - nothing exceptional about it!

Now, an error due to a hardware failure while reading the disk is
exceptional:
disks tend to be very reliable these days ...

Regards,

Arjen

"Jan Vorbr�ggen" <jvorbrueggen-not@mediasec.de> wrote in message
news:2kkfjeF3clltU1@uni-berlin.de...
> It's somewhat similar to marriage, when the attending crowd is told
> that any objections should be spoken out then, or one should remain
forever
> silent (I only know the proper wording in German, not in English) 8-)...
>
Roughly: "If any of ye know of any just cause or impediment why these two
people may not, severally, be joined together in holy matrimony, let them
now speak or for ever hold their peace" (from an ex-choirboy's memory).

Regards,

Mike Metcalf

Michael Metcalf wrote:

>>It's somewhat similar to marriage, when the attending crowd is told
>>that any objections should be spoken out then, or one should remain
>>forever silent (I only know the proper wording in German, not in English) 8-)...
>
> Roughly: "If any of ye know of any just cause or impediment why these two
> people may not, severally, be joined together in holy matrimony, let them
> now speak or for ever hold their peace" (from an ex-choirboy's memory).

Digging up the oldest (English) BCP I can find online (1559):

"Therefore if any man can shewe any just cause, why thei may not 
lawfully be joyned together let hym now speake, or els hereafter for 
ever holde his peace."

By 1979, this had become

"If any of you can show just cause why they may not lawfully be
married, speak now; or else for ever hold your peace."

And that concludes todays lesson on liturgical history ;-)

Richard

Gary L. Scott wrote:

>>It does seem far more plausible to me that a new standard might
>>demand the equivalent of a compiler switch than that a new
>>standard would invalidate that much existing code.  
> 
> I bet no vendors would seriously object to a switch for backward
> compatibility.

My experience is not wide (and is only recent), but I've yet to see a 
compiler which doesn't have a switch to stuff an IMPLICIT NONE 
everywhere it's legal to have one.

Richard Maine:
>>but I still think that it would look to bad
>>on paper (and thus in legal matters) to have the standard
>>officially declare such code invalid; the "wink.  It is ok
>>with real compilers anyway" wouldn't be good enough.

Your point is taken, but.... I suspect that's the sort of reasoning that 
has left gets() in C99.

Richard

"James Giles" <jamesgiles@worldnet.att.net> wrote in message news:<oL2Fc.174561$Gx4.94477@bgtnsc04-news.ops.worldnet.att.net>...
> Gary L. Scott wrote:
> > Richard Maine wrote:
>  ...
> >> It does seem far more plausible to me that a new standard might
> >> demand the equivalent of a compiler switch than that a new
> >> standard would invalidate that much existing code.
> >
> > I bet no vendors would seriously object to a switch for backward
> > compatibility.
> 
> 
> Actually, I would bet that most vendors would object to
> making non-standard behavior the default.

? We've just made it "standard" in my argument so the non-standard
behaviour is now to assume implicit none.  User's with old code (F95
compliant) simply use a switch to get the old behaviour.  What's so
hard about that?

"James Giles" <jamesgiles@worldnet.att.net> wrote in message news:<oL2Fc.174561$Gx4.94477@bgtnsc04-news.ops.worldnet.att.net>...
> Gary L. Scott wrote:
> > Richard Maine wrote:
>  ...
> >> It does seem far more plausible to me that a new standard might
> >> demand the equivalent of a compiler switch than that a new
> >> standard would invalidate that much existing code.
> >
> > I bet no vendors would seriously object to a switch for backward
> > compatibility.
> 
> 
> Actually, I would bet that most vendors would object to
> making non-standard behavior the default.

? We've just made it "standard" in my argument so the (!@&$ deleted)
standard behaviour is now to assume implicit none.  User's with old
code (F95 compliant) simply use a switch to get the old behaviour. 
What's so hard about that?

Jan Vorbr�ggen wrote:
> 
>  > Fortran does not, and F2003 still won't, have a real structured
> > exception handling (e.g., try/throw/catch) functionality.  This is a fairly
> > large hole in Fortran (compared to C++/Java/Python/ADA/PL1/etc.)
> 
> I have my doubts on the actual, day-to-day usefulness of exception handling...

I don't.  I tend to program defensively.  In some cases probably 50% of my
code is checking on return codes from various things and handling them, so that
I don't end up with some cascading error or abend.

>  Things like better tracebacks when errors
> are detected - yes, that is ubiquitously useful, but how many compilers except 
> those derived from the DEC compilers have that?

The compilers I've used have all had traceback capabilities - given that the
application is built with the correct magical incantation.  However, the real
goal when writing reliable software is to avoid tracebacks altogether.  There
should be exactly one STOP statement in the code - and that is when the user
has successfully finished his work with the application.

> The problem with exception handling is that you need to think through what
> _could_ happen at any place in the code and in time, and those considerations
> better be exhaustive, and _decide_ what to do in all or at least a large
> fraction of those cases. That is hard work...

The advantage of generalized error catching is that you DON'T have to think
through and code for each and every error condition.  You can handle the
errors you are interested in, then use a 'catchall' for the rest.

There are also errors which are impossible or impractical to catch in the current
Fortran spec.  For example:  How does one recover from a call to a subroutine - when
there is not enough stack space for the callees local variables?  We've all had this
happen to us.  Yet there is no current syntax in the Fortran language to handle this
case.  And even if there were, would one really want to recode dozens/hundreds of
subroutine calls to use the capabilitiy?  And what about function calls?  Ick.

Another textbook case: checking each and every floating point calculation for NaN,
underflow, overflow, etc.  To do this would be incredibly tedious and slow, and is
usually unneeded.  So one never sees it.  Yet how many of us have had problems merrily
compute along with bad numbers?  Then we have to spend a lot of debugging time tracing
back to where the problem started?

James Giles has a new .sig in his postings which describes the situation exactly:

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

A structured try/catch/throw-like capability would eventually allow removal of
much error checking code, and segregating/unifying the rest.  This can't help
but make the code much simpler, more understandable, and more reliable.  As I
mentioned previously, many other modern languages do have these capabilities,
and will continue to build on them in the future.

Walt
-...-
Walt Spector
(w6ws at earthlink dot net)

Walter Spector wrote:
....
> James Giles has a new .sig in his postings which describes the situation
> exactly:
>
>> "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
>
> A structured try/catch/throw-like capability would eventually allow
> removal of  much error checking code, and segregating/unifying the
> rest.  This can't help but make the code much simpler, more understandable,
> and more reliable.  As I mentioned previously, many other modern
> languages do have these capabilities, and will continue to build on
> them in the future.

Well, actually a exception handling is usually a very
complicated beast.  When most people talk about exception
handling, they assume something that actually does several
different things.  Is it only a means  of detecting hardware
generated faults and traps?  No.  Is it "merely" a new (and
always non-structured) control flow feature?  No.  Is it
"merely" the introduction of a new and distinctly different
scoping rule?  No.  It's usually all those things, and something
to do with externally generated signals as well (which are really
completely different beasts semantically).

If we really want a new, non-structured control construct, why
not introduce it directly?  If we want a way to detect hardware
generated faults and traps, why does it need to be inherently bound
to this new control construct?

If we really want a new scope rule (that symbols can be declared
that implicitly are visible in all procedures called by the scope
that originally declares them), why not introduce that directly?
Does the detection of hardware traps and faults really need to
be inherently bound to that scoping rule? I can't help but think
that this particular scope rule would not be very appealing
as a general feature (and I don't find it appealing for exceptions).

It seem to me that if we actually address *directly* what it is
we want to do with exceptions it is likely we'll be able to
think of a simpler and easier to use feature than if we rubber-
stamp the style of feature already present in other languages.
On the other hand, I have a nightmare that the committee will
just adopt setjump/longjump as part of some future round of
C interop.

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

"James Giles" <jamesgiles@worldnet.att.net> writes:

> On the other hand, I have a nightmare that the committee will
> just adopt setjump/longjump as part of some future round of
> C interop.

Arghhhhhhhhhhh!!!!! :-(

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

Richard Maine wrote:
> "James Giles" <jamesgiles@worldnet.att.net> writes:
>
>> On the other hand, I have a nightmare that the committee will
>> just adopt setjump/longjump as part of some future round of
>> C interop.
>
> Arghhhhhhhhhhh!!!!! :-(


Same nightmare huh?

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

On 2 Jul 2004 07:39:30 -0700, gary.l.scott@lmco.com (Gary Scott)
wrote:

>? We've just made it "standard" in my argument so the non-standard
>behaviour is now to assume implicit none.  User's with old code (F95
>compliant) simply use a switch to get the old behaviour.  What's so
>hard about that?

If something is declared to be standard, then it really takes more
than a whim to declare it to be non-standard.  People count on
standards - the the very idea of a standard it that it defines the
accepted way of doing things, one that will be stable.  Arbitrarily
change things, and there is no point to standards.

I suppose I should be confused by the denigration of Fortran's
implicit typing.  I find the implicit rule that i-n is integer and
other letters to be real to a tremendous asset.  Ihave been involved
with one program for almost 30 years that was originally written by
someone else, that does not follow that rule.  Having to flip back to
the declarations to see what type a variable is constantly drives me
nuts.

Doesn't anyone else consider consistent naming of variable so their
type is apparent to be a Good Thing, worthy of being standard?

Ken Plotkin

Gerry Thomas wrote:

> In what language(s) are Fortran compilers written in (tough!) ?

Grammar!  There is no reason for "in" at the end when you have it at the 
beginning.  You might think this is nit-picking, but in human languages, 
as in computer languages, details are sometimes very important.

HTH

Gib

Marco A. Cruz Q. wrote:

> August Miller <amiller@dirac.nmsu.edu> wrote in message news:<cbug7s$36k$1@bubba.nmsu.edu>...
> 
>>As they say, FWIW:
>>
>>In 16 years of doing a few things in various flavors of C, and 43+
>>years of FORTRAN, I have yet to find a C or C++ compiler which
>>can evaluate (without further ado)  the equivalent of
>>
>>Z3=Z1*SIN(Z2)
>>
>>where all the variables are complex numbers.
> 
> 
> Finally, a good answer!

That response seems to indicate either that you don't read carefully, or 
that you have already made up your mind.  You received many good answers.

Gib

James Giles wrote:
> ...
> Well, actually a exception handling is usually a very
> complicated beast.  When most people talk about exception
> handling, they assume something that actually does several
> different things...

Never said it would be easy for the compiler/library writers.
But that is why they get paid the Big Bucks.  :-)

> ...
> It seem to me that if we actually address *directly* what it is
> we want to do with exceptions it is likely we'll be able to
> think of a simpler and easier to use feature than if we rubber-
> stamp the style of feature already present in other languages.

I do not claim to be any sort of expert in this area.  Just observing
what I see in other languages and thinking how some sort of comparable
feature would affect Fortran code.  So my first approach would be
(and has been) to look at what is in C++/Python/Java/PL1/ADA/etal as one
possibility.  Pretty much all of them use some variant of structured
try/catch blocks.

If you have ideas for a better way of expressing things, I'm all ears.

> On the other hand, I have a nightmare that the committee will
> just adopt setjump/longjump as part of some future round of
> C interop.

Yuck.

At a minimum, they should look at Java and think about something similar.
If they can come up with a better way to do things, so be it.

Walt
-...-
Walt Spector
(w6ws at earthlink dot net)

"bv" <bvoh@Xsdynamix.com> wrote in message
news:40E329ED.6DC28BD@Xsdynamix.com...
> "E. Robert Tisdale" wrote:
> >
> > > Is it really necessary to use FORTRAN?
> > No.
>
> Right on ET, especially if taxpayers money's no object! How's that multi
> million Fortran -> C++ conversion (as described by Van Snyder) fiasco
> going??
>

Fortran obscurantism and its hereto-unchallenged pretentiousness has cost
taxpayers untold monies. It's obscure because it's legacy architects are
dead; self-styled scientists/engineers in government-funded and
industropsuedoacademic (and of course the real McCoy university academic
parasites) sinecure positions, besides being stagnant and near comatose in
outlook, are in denial of Fortran's significant shortcoming as relevant to
the current millennium. J3 can issue Fortran's for all anyone cares other
than it's aging devotees, as anyone with an iota of sense will continue to
ignore Fortran and ultimately (give it 15-20 yrs, tops) it'll pass into
oblivion were it'll leave no memory of it ever having existed. Sure reality
sucks, so get used to it, there's more (reality) to follow, whether J3
likes it or not, but they truly don't give a damn.

-- 
You're Welcome,
Gerry T.
______
"Things are not what they seem; or, to be more accurate, they are not only
what they seem, but very much else besides." -- Aldous Huxley.

"Walter Spector" <w6ws_xthisoutx@earthlink.net> wrote in message
news:40E58B96.850C7196@earthlink.net...

> The compilers I've used have all had traceback capabilities

Courtesy of C/C++. You'll be dead before Fortran provides native exception
handling.

Fortran, RIP.

-- 
You're Welcome,
Gerry T.
______
"Things are not what they seem; or, to be more accurate, they are not only
what they seem, but very much else besides." -- Aldous Huxley.

Richard Edgar <rge21@astro.su.se> wrote in message news:<cc36oc$rjl$1@news.su.se>...
> Michael Metcalf wrote:
> 
> >>It's somewhat similar to marriage, when the attending crowd is told
> >>that any objections should be spoken out then, or one should remain
> >>forever silent (I only know the proper wording in German, not in English) 8-)...
> >
> > Roughly: "If any of ye know of any just cause or impediment why these two
> > people may not, severally, be joined together in holy matrimony, let them
> > now speak or for ever hold their peace" (from an ex-choirboy's memory).
> 
> Digging up the oldest (English) BCP I can find online (1559):
> 
> "Therefore if any man can shewe any just cause, why thei may not 
> lawfully be joyned together let hym now speake, or els hereafter for 
> ever holde his peace."
> 
> By 1979, this had become
> 
> "If any of you can show just cause why they may not lawfully be
> married, speak now; or else for ever hold your peace."
> 
> And that concludes todays lesson on liturgical history ;-)
> 
> Richard

All this [OT] reminds me the following scenes, quoted from "THE
GRADUATE" Screenplay by Buck Henry.

Salud,
Pablo

"""
250	EXT. STREET IN FRONT OF CHURCH - DAY (2:15 PM) - SHOT OF
	BEN

	Running across the street.  He stops for a moment and looks
	around.  There are a number of cars parked in front of the
	church.  Among them is Mrs. Robinson's car.  Ben runs by
	it and up the steps to the front doors of the church.

251	EXT. CHURCH - DAY - SHOT OF BEN

	He pulls at the doors.  They are locked.  Through the glass
	doors, we can see to the front of the church where the
	wedding ceremony is taking place.

252	EXT. SIDE OF CHURCH - DAY - SHOT OF BEN

	running around the side of the church.  There are glass
	windows and doors through which, as he runs, we can see
	the ceremony continuing.

253	EXT. BACK OF CHURCH - DAY

	Ben runs, looking for an entrance.  He goes all the way
	around the church and stops at a side door.  He opens the
	door and goes in.

254	INT. CHURCH - BALCONY - DAY

	The balcony is between two huge windows, one of which looks
	out on the lawn outside, the other looks into the interior
	of the church where the ceremony is taking place.  The sun
	is coming through the window.  Ben stops and looks through
	the inside window.  The minister is just closing the book.
	He says something and Carl and Elaine kiss.

				BEN
		Oh, Jesus - God - no -

	He puts his hands up against the glass and slumps.  The
	minister shakes hands with Carl, then takes Elaine's hand.
	The ORGAN music starts to THUNDER.

				BEN
			(straightening)
		No!

	He moves to the center of the window and begins to POUND
	on the glass.

				BEN
		Elaine - Elaine!

	Ben's shadow is thrown across the celebrants.  They all
	turn around and look up at him.

256	INT. CHURCH - DAY - SHOT FROM FRONT OF CHURCH

	Ben is like a trapped moth, beating on the window and yelling
	soundlessly.

257	SHOT - MRS. ROBINSON

	She looks up at Ben with a small, triumphant smile.

258	SHOT - MR. ROBINSON

	looking up at Ben.

259	SHOT - CARL

	looking up at Ben.

260	SHOT - ELAINE

	looking up at Ben.  She moves down the aisle toward him,
	dazed.

261	SHOT - ALL OF THEM

	Mr. Robinson, Carl, and Mrs. Robinson are moving toward
	Elaine.  The ORGAN is playing LOUDLY.  Ben's voice can
	be heard SHOUTING Elaine's name.  The POUNDING on the
	glass can be heard.

				CARL
		Who is that guy?  What's he doing?

				MR. ROBINSON
		I'll take care of him.

				MRS. ROBINSON
		He's too late.

	The other guests are adlibbing their confusion.

262	SHOT - ELAINE

	She turns back toward her mother, father and Carl as they
	come toward her.

263	CLOSEUP - ELAINE

	looking at them.  ALL SOUND STOPS, except for Ben's
	voice in the distance shouting "ELAIN ELAINE ELAINE."

264	ELAINE'S POV - CARL

	Frozen frame.

265	ELAINE'S POV - MR. ROBINSON

	Frozen frame.

266	ELAINE'S POV - MRS. ROBINSON

	Frozen frame.

267	SHOT - ELAINE

	Her face turning quickly to look up at Ben.

268	ELAINE'S POV - BEN

	Frozen frame.  His face twisted with passion, his body
	spread-eagled against the glass.

269	CLOSEUP - ELAINE

	looking up at Ben.

				ELAINE
			(screaming)
		Ben!

	The SOUND of the ORGAN and the guests' VOICES starts again.

270	INT. CHURCH VESTIBULE - STAIRS - DAY - SHOT - BEN

	He starts to go back down the stairs.  He reaches the
	bottom of the stairs and goes through a door which leads
	into the vestibule of the church.

271	INT. CHURCH VESTIBULE - DAY

	Mr. Robinson is waiting for Ben, crouching, his arms spread.
	Behind him is Elaine.  Ben moves toward them.  Mr. Robinson
	grabs Ben around the waist.  Ben twists away.  Mr. Robinson
	grabs Ben's collar and tears his jacket half off.  Ben
	turns and hits Mr. Robinson in the face.  Mr. Robinson
	falls down.  Ben moves to Elaine and grabs her hand.  He
	pulls her toward the doors.

				BEN
		Come on - don't faint.

272	SHOT - THE ORGANIST

	His back to the action, clawing away at the organ
	obliviously.

273	SHOT - THE DOOR

	A man in clerical garb is guarding the door.  Ben and
	Elaine move toward the door.

				BEN
		Out of my way!

	Carl steps in and grabs Ben from behind.  Ben breaks
	Carl's hold and picks up a gold cross off a nearby stand.
	He begins to swing it, advancing toward Carl.  Carl
	backs up toward the other guests.

274	NEW ANGLE

	Mrs. Robinson steps to Elaine.  She reaches out and takes
	Elaine's wrist.

				MRS. ROBINSON
		Elaine - it's too late.

	Elaine pulls her hand away.

				ELAINE
		Not for me.
"""

Ken Plotkin wrote:

> Doesn't anyone else consider consistent naming of variable so their
> type is apparent to be a Good Thing, worthy of being standard?

It's certainly a Good Idea to keep some sort of consistency - although I 
doubt it should be enshrined in the language standard. There is nothing 
_preventing_ you from having consistent naming with IMPLICIT NONE in 
place. However, the problem with implicit typing is that it turns typos 
into bugs - sometimes very subtle ones.

Richard

Ken Plotkin wrote:
> 
> On 2 Jul 2004 07:39:30 -0700, gary.l.scott@lmco.com (Gary Scott)
> wrote:
> 
> >? We've just made it "standard" in my argument so the non-standard
> >behaviour is now to assume implicit none.  User's with old code (F95
> >compliant) simply use a switch to get the old behaviour.  What's so
> >hard about that?
> 
> If something is declared to be standard, then it really takes more
> than a whim to declare it to be non-standard.  People count on
> standards - the the very idea of a standard it that it defines the
> accepted way of doing things, one that will be stable.  Arbitrarily
> change things, and there is no point to standards.
> 

I agree generally, but this choice was just plain wrong.  Fixing things
that are just plain wrong is acceptable in my opinion (those last three
words being of course key here).

> I suppose I should be confused by the denigration of Fortran's
> implicit typing.  I find the implicit rule that i-n is integer and
> other letters to be real to a tremendous asset.  Ihave been involved
> with one program for almost 30 years that was originally written by
> someone else, that does not follow that rule.  Having to flip back to
> the declarations to see what type a variable is constantly drives me
> nuts.

Implicit typing has never been a major cause of error for myself,
however most arguments that I've heard indicate that it can be a major
or at least significant source of errors.  It is considered by most to
be bad practice.  I tend to disagree in that I very much LIKE default
behaviors (especially when it comes to things like GUI APIs).  All you
need to do is memorize (or have reference for) those default behaviors.

> 
> Doesn't anyone else consider consistent naming of variable so their
> type is apparent to be a Good Thing, worthy of being standard?

I personally use it all the time for quick and dirty tests and such. 
However a command line switch to get that behavior would be of
exceedingly minimal bother.  I am perfectly happy if it only applies to
free form source also since that's where I think the mistake was made
and that would impact far fewer applications.

> 
> Ken Plotkin


-- 

Gary Scott
mailto:garyscott@ev1.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

Why are there two?  God only knows.

Democracy is two wolves and a sheep, voting on what to eat for dinner...
Liberty is a well armed sheep contesting the vote. - Thomas Jefferson

s8ngsu3@yahoo.com (r08n) wrote in message news:<27828186.0407010028.23be838a@posting.google.com>...

> 3)  I/O handling less flexible and convenient than <iostream>
> operations.

When it comes to formatted I/O, I think Fortran > C (stdio) > C++
(iostream). Consider the following equivalents.

Fortran:
   print "(3f8.2)",x,y,z

C stdio:
   printf("%8.2f%8.2f%8.2f",x,y,z)

C++ iostream:
   cout << setprecision(2) << setiosflags(ios::fixed) 
   << setw(8) << x << setw(8) << y << setw(8) << z << endl;

Two advantages of Fortran I/O over C I/O are that 
(1) "3f8.2" is a convenient shorthand for "f8.2f,f8.2,f8.2", which C
lacks.
(2) If the format is "3f8.2", up to 3 floats can be formatted, but in
C, EXACTLY 3 floats must be formatted.

Maybe a disadvantage of Fortran I/O is that there is no "\n" character
for a new line -- one must use "/" in the FORMAT.

The advantages of Fortran over C++ iostream formatted I/O is obvious.
In the C++ example above, it will take a programmer some time to write
the code and later to understand it. Writing and understanding the
Fortran and C code is instantaneous. Simple things should be done
simply!

I know Fortran 2003 has stream I/O, but I don't know what it is about.
I hope it does not resemble C++ iostream.

<beliavsky@aol.com> wrote in message
news:3064b51d.0407031321.499f8f30@posting.google.com...
> s8ngsu3@yahoo.com (r08n) wrote in message
news:<27828186.0407010028.23be838a@posting.google.com>...
>
> > 3)  I/O handling less flexible and convenient than <iostream>
> > operations.
>
> When it comes to formatted I/O, I think Fortran > C (stdio) > C++
> (iostream). Consider the following equivalents.
>
> Fortran:
>    print "(3f8.2)",x,y,z
>
> C stdio:
>    printf("%8.2f%8.2f%8.2f",x,y,z)
>
> C++ iostream:
>    cout << setprecision(2) << setiosflags(ios::fixed)
>    << setw(8) << x << setw(8) << y << setw(8) << z << endl;
>
> Two advantages of Fortran I/O over C I/O are that
> (1) "3f8.2" is a convenient shorthand for "f8.2f,f8.2,f8.2", which C
> lacks.
> (2) If the format is "3f8.2", up to 3 floats can be formatted, but in
> C, EXACTLY 3 floats must be formatted.
>
> Maybe a disadvantage of Fortran I/O is that there is no "\n" character
> for a new line -- one must use "/" in the FORMAT.
>
> The advantages of Fortran over C++ iostream formatted I/O is obvious.
> In the C++ example above, it will take a programmer some time to write
> the code and later to understand it. Writing and understanding the
> Fortran and C code is instantaneous. Simple things should be done
> simply!
>
> I know Fortran 2003 has stream I/O, but I don't know what it is about.
> I hope it does not resemble C++ iostream.

Fortran (any version) I/O is a crock relative to C/C++. This is a statement
of opinion and I'm not open to futile proselytizing, it's certainly a
cardinal carrot that I wave and share with colleagues.

-- 
Bye,
Gerry T.

On 3 Jul 2004 14:21:02 -0700, beliavsky@aol.com wrote:

[snip]
>Maybe a disadvantage of Fortran I/O is that there is no "\n" character
>for a new line -- one must use "/" in the FORMAT.

I don't think there is a standard way to suppress line end in Fortran.
"/" does it in CVF, but is not standard.  At one time combinations of
+ and/or $ worked, and were so common I thought they were standard,
but they weren't.

>
>The advantages of Fortran over C++ iostream formatted I/O is obvious.
>In the C++ example above, it will take a programmer some time to write
>the code and later to understand it. Writing and understanding the
>Fortran and C code is instantaneous. Simple things should be done
>simply!

Human readable code?  There goes job security for obscurists!

>I know Fortran 2003 has stream I/O, but I don't know what it is about.
>I hope it does not resemble C++ iostream.

No, it doesn't.  Its basic structure is the same as unformatted, but
without record markers.  Essentially standardizing what a lot of
compilers had as "binary" or "transparent."  I don't know if there's a
formatted version of it, but I can't picture the committee not having
added that to the feature.

Ken Plotkin

Walter Spector wrote:
> James Giles wrote:
>> ...
>> Well, actually a exception handling is usually a very
>> complicated beast.  When most people talk about exception
>> handling, they assume something that actually does several
>> different things...
>
> Never said it would be easy for the compiler/library writers.
> But that is why they get paid the Big Bucks.  :-)
....
> At a minimum, they should look at Java and think about something similar.
> If they can come up with a better way to do things, so be it.

The Java method, aside from syntax, is nothing particularly
new.  The try/catch blocks are essentially Zahn's construct
(see "Structured Programming with GOTO Statements",
D.E. Knuth, Computing surveys, vol 6, no 4, Dec. 1974).
And, though the Java people would go livid with anger
at the characterization, the throw from one procedure to
another is actually very similar to Fortran alternate returns.

Zahn's construct, in various forms, often comes up in
discussions of exception handling.  Ada's feature is a variant.
It's been suggested for Fortran clear back to the early '80s,
if not before.  There are some problems with it.  First of
all, structured programming purists would insist on pointing
out that it is *not* structured: the advent of an exception is
followed by a branch to the handler.  Well, purists aside,
it's no less structured than EXIT or CYCLE.

Another problem with it is that it's not necessarily what
everyone whants to have happen when an exception occurs.
Consider a simple possibility: integer divide by zero. In
my own code, what I most often want this to do is halt
immediately: no "cleanup", no handling of any kind.  I want
the traceback and other information from the system left
as unchanged as possible in order to better discover the
cause of the problem (the lack of dropfiles and other useful
features in most systems is also very bad).  The second most
common response to divide by zero that I want in my own
code is to replace the result of the divide with a canonical
default value (or set a flag) and continue processing as if the
exception never happened.  The Zahn's construct style of
response is only the third most common thing I want to do
with the condition.

So, the problem is that you are assuming that the new "semi-
structured" control construct should *necessarily* be inherently
bound to the detection and response to exceptional conditions.
Surely those are two different issues.  Personally, I like Zahn's
construct and think a form of it would be useful in Fortran, but
that doesn't necessarily address the issue of exceptions at all.
And, there is a completely different style of exception handling
that should at least be considered.  This is the PL/I style.

In PL/I, a block of code can be associated with an exception
name.  When the exception occurs, the block of code is invoked
and, when the block completes, control resumes at the point of
the exception.  That is, the handler is invoked as a procedure
call.  The structured programming purists would accept this as
genuinely structured (procedure calls are acceptable).  And
this kind of handler almost, but not quite, permits the response
that I mentioned as my second most common desire.  Unfortunately,
that requires hardware support that's rare and PL/I is designe
with the assumption that it's not possible (that is, even if the
hardware did support it, PL/I still wouldn't).

In order to handle the exception in the way that I'd like, the
hardware needs to send, as arguments to the handler, the values
of the operands to the failed instruction.  And, it needs to accept,
as the result of the handler, a structure that includes all the
results, flags, codes, etc. that the failed instruction would
generate.  The PL/I exception handlers take no arguments and
return no results.  Even so, it's a form that might be considered.
Whether PL/I exceptions are adopted or not is independent
of the question of whether Zahn's construct is adopted as
a new control construct.


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

On Sat, 3 Jul 2004 21:29:44 UTC, "Gerry Thomas" 
<gfthomas@sympatico.ca> wrote:

Sir 
       you're pisssing me off.

Plonk

-- 
Cheers - Dave.

On Sat, 3 Jul 2004 21:21:02 UTC, beliavsky@aol.com wrote:

> s8ngsu3@yahoo.com (r08n) wrote in message news:<27828186.0407010028.23be838a@posting.google.com>...
> 
> > 3)  I/O handling less flexible and convenient than <iostream>
> > operations.
> 
> When it comes to formatted I/O, I think Fortran > C (stdio) > C++
> (iostream). Consider the following equivalents.
> 
> Fortran:
>    print "(3f8.2)",x,y,z
> 
> C stdio:
>    printf("%8.2f%8.2f%8.2f",x,y,z)
> 
> C++ iostream:
>    cout << setprecision(2) << setiosflags(ios::fixed) 
>    << setw(8) << x << setw(8) << y << setw(8) << z << endl;
> 
> Two advantages of Fortran I/O over C I/O are that 
> (1) "3f8.2" is a convenient shorthand for "f8.2f,f8.2,f8.2", which C
> lacks.
> (2) If the format is "3f8.2", up to 3 floats can be formatted, but in
> C, EXACTLY 3 floats must be formatted.
> 
> Maybe a disadvantage of Fortran I/O is that there is no "\n" character
> for a new line -- one must use "/" in the FORMAT.
> 
> The advantages of Fortran over C++ iostream formatted I/O is obvious.
> In the C++ example above, it will take a programmer some time to write
> the code and later to understand it. Writing and understanding the
> Fortran and C code is instantaneous. Simple things should be done
> simply!
> 
> I know Fortran 2003 has stream I/O, but I don't know what it is about.
> I hope it does not resemble C++ iostream.

Fortran formatted i/o has one other great advantage over C. The format
statements are parsed by the compiler and the relavant subroutines 
called. Hence, the linker calls in only those routines required. 
'printf' OTOH is just a normal C variarable argument-count function. 
The linker requires printf and then everything else that printf 
requires. Net result is a larger executable and, once upon a time on 
x86, even or integer-only programs,  floating point processor support 
(unless you used the integer only switch).
 
-- 
Cheers - Dave.

On 4 Jul 2004 07:12:45 GMT, "Dave Weatherall"
<djw-nothere@nospam.nohow> wrote:


>you're pisssing me off.

You're only encouraging him by letting him know that.

>Plonk

Best done silently - now he knows he's added a notch, and will double
his efforts.

Ken Plotkin <kplotkin@nospam-cox.net> writes:

> On 3 Jul 2004 14:21:02 -0700, beliavsky@aol.com wrote:
>
> [snip]
>>Maybe a disadvantage of Fortran I/O is that there is no "\n" character
>>for a new line -- one must use "/" in the FORMAT.
>
> I don't think there is a standard way to suppress line end in Fortran.
> "/" does it in CVF, but is not standard.  At one time combinations of
> + and/or $ worked, and were so common I thought they were standard,
> but they weren't.

You mean "\" instead of "/" for supressing newline I suspect.
Nonadvancing I/O is a standard way to supress newlines as of f90.
However, note that Beliavsky was writing about how to *INSERT*, not
supress, newlines.  The fundamental issue here is that, up through
f95, you can only do that in the format; there is no standard way to
put something in the data stream that will cause a newline.  F2003
does add such a beast (at least for formatted stream; I'm now having
trouble recalling whether it applies to formatted sequential, but
I think it does).

>>I know Fortran 2003 has stream I/O, but I don't know what it is about.
>>I hope it does not resemble C++ iostream.
>
> No, it doesn't.  Its basic structure is the same as unformatted, but
> without record markers.  Essentially standardizing what a lot of
> compilers had as "binary" or "transparent."  I don't know if there's a
> formatted version of it, but I can't picture the committee not having
> added that to the feature.

When I wrote up the first draft of it, I didn't have formatted stream.
The applications that I thought critical were for unformatted.
Plus, I was trying to keep it simple in order to maximize its
chance of acceptance.  Turned out that I need not have worried
about the odds of acceptance - it got strong support, the main complaint
being that many people wanted formatted stream also.  So formatted
got added also.  Though it isn't horribly complicated, it is much
more so than unformatted stream.  There's not much to get wrong in
unformatted stream (ok, a few small things, but not much).  There
are quite a few tricky points about formatted stream - several of
them having to do with newlines.

-- 
Richard Maine
email: my last name at domain
domain: summertriangle dot net

On Sun, 04 Jul 2004 09:18:31 -0700, Richard Maine
<nospam@see.signature> wrote:


>You mean "\" instead of "/" for supressing newline I suspect.
[snip]

Yep...time for that bee farm on the Sussex downs.  Talk of stream I/O
made me think of continuous streams of stuff, without breaks.  Don't
use Unix enough for \n - which I actually do know - to have broken
through the fog.


>When I wrote up the first draft of it, I didn't have formatted stream.
>The applications that I thought critical were for unformatted.
>Plus, I was trying to keep it simple in order to maximize its
[snip]

Is everyone who thinks Richard is feature-mad listening?

Ken Plotkin

On Sun, 4 Jul 2004 15:54:56 UTC, Ken Plotkin <kplotkin@nospam-cox.net>
wrote:

> On 4 Jul 2004 07:12:45 GMT, "Dave Weatherall"
> <djw-nothere@nospam.nohow> wrote:
> 
> 
> >you're pisssing me off.
> 
> You're only encouraging him by letting him know that.
> 
> >Plonk
> 
> Best done silently - now he knows he's added a notch, and will double
> his efforts.

Point taken.

-- 
Cheers - Dave.

beliavsky@aol.com wrote in message news:<3064b51d.0407031321.499f8f30@posting.google.com>...
 
> Maybe a disadvantage of Fortran I/O is that there is no "\n" character
> for a new line -- one must use "/" in the FORMAT.

The biggest pain for me is an absence of nonadvancing _input_, i.e.,
each new
READ statement starts reading from a new line (or am I still not
advanced enough in fortran?) 

(Slightly OT):
For example, I want to read the
parameters from a text file
that looks like this:

# This is a comment
parameter1=42.7 # this parameter has a 'float' value
parameter2= 12 # and this one is integer
# and so on

So I wrote a parser that opens this file for direct access, with
record length = sizeof(char), and reads a single character at a time.
Are there any better options?

r08n wrote:
> 
> beliavsky@aol.com wrote in message news:<3064b51d.0407031321.499f8f30@posting.google.com>...
> 
> > Maybe a disadvantage of Fortran I/O is that there is no "\n" character
> > for a new line -- one must use "/" in the FORMAT.
> 
> The biggest pain for me is an absence of nonadvancing _input_, i.e.,
> each new
> READ statement starts reading from a new line (or am I still not
> advanced enough in fortran?)
> 
> (Slightly OT):
> For example, I want to read the
> parameters from a text file
> that looks like this:
> 
> # This is a comment
> parameter1=42.7 # this parameter has a 'float' value
> parameter2= 12 # and this one is integer
> # and so on
> 
> So I wrote a parser that opens this file for direct access, with
> record length = sizeof(char), and reads a single character at a time.
> Are there any better options?

Yes, nonadvancing input can be done via:

read(10,format,advance='no') string   ! list-directed format is not
possible with advancing input

And in the above case, 

read(10,'(a)') string
k = index(string,'=')
read(string(k+1:),*) value

(and the like) would be simpler ...

Regards,

Arjen

s8ngsu3@yahoo.com (r08n) writes:

> The biggest pain for me is an absence of nonadvancing _input_,...

Nonadvancing I/O works prefectly fine for input; that's the "I"
part of the "I/O".  It does require at least Forrtan 90; there
is no good, portable Fortran 77 solution.

>...
> # This is a comment
> parameter1=42.7 # this parameter has a 'float' value
> parameter2= 12 # and this one is integer

I'd agree with Arjen that the simplest way to read this file is
to read each line into a single character string and then parse
the string internally.  See his post for sample ideas; I suspect
you can fill in the rest of the details.

> So I wrote a parser that opens this file for direct access, with
> record length = sizeof(char), and reads a single character at a time.
> Are there any better options?

See above (and Arjen's post) for 2 ideas.  Using direct access here
has several portability problems in practice, in addition to being
extra nuisance.

1. I think all, or at least most, current compilers will let you
   open a direct access file with a record length of one character,
   but it certainly hasn't always been so.  There have been systems
   where the record length was in words and could not be changed to
   characters.  There have also been systems where a record length
   of 1 was special-cased to mean something like stream I/O.
   Probably not a big problem today, but an issue to keep at least
   in the back of your mind.

2. In reading a sequential file as direct access, you will have to
   do your own translation of the record structure.  In particular,
   you'll have issues moving among Windows and Unix boxes, which use
   different line end conventions.  And old Mac boxes used another one,
   but OS-X is essentially a Unix now.  You can write code in a way that
   it is easly adopted to all 3 of those schemes; with a little
   work, you could probably even manage a single code that was
   flexible enough to work for all 3 without change, but it is
   extra bother.  Then there are operating systems where text file
   line ends aren't indicated by control characters at all (VAX and others).

3. I was thinking there was another issue I recalled, but I've now
   forgotten what I had in mind.  Hmm.  There are complications
   with detecting the end of file, but that wasn't it.

Anyway.  These aren't completely unmanagable.  They will,
however, cause some portability headaches, particularly the
line-end difference.

I think the "read each line into a character variable and then
parse that" approach is by far the simplest here.

-- 
Richard Maine
email: my last name at domain
domain: summertriangle dot net

"Dave Weatherall" <djw-nothere@nospam.nohow> writes:

> Fortran formatted i/o has one other great advantage over C. The format
> statements are parsed by the compiler and the relavant subroutines 
> called. Hence, the linker calls in only those routines required. 

That was the case in Foortran 66.  As of Fortran 77, formats can be character
expressions that need not be known at compile time.  It is, of course, still
true that a program can restrict itself to compile-time formats, but that's
a pretty significant restriction unlikely to be held to for a code of much
size - of course for a code of much size, the I/O library won't be as big a
part of the overall program.

Note also that I/O libraries are likely to be implemented in shared libraries,
where there is not significant cost to linking the whole thing.  Once you
have linked to anything at all in the shared library, you've bitten off most
of the costs.

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

Richard Maine wrote:
> "Dave Weatherall" <djw-nothere@nospam.nohow> writes:

>>Fortran formatted i/o has one other great advantage over C. The format
>>statements are parsed by the compiler and the relavant subroutines 
>>called. Hence, the linker calls in only those routines required. 

Most C format specifications are string constants, and are at
least checked by the compiler.  It might be that some do more
processing on them, too.

> That was the case in Foortran 66.  As of Fortran 77, formats can be character
> expressions that need not be known at compile time.  It is, of course, still
> true that a program can restrict itself to compile-time formats, but that's
> a pretty significant restriction unlikely to be held to for a code of much
> size - of course for a code of much size, the I/O library won't be as big a
> part of the overall program.

Fortran 66 allowed variable format specifications in an array.
No CHARACTER variables, but there were Hollerith constants
and A format to read them in.

> Note also that I/O libraries are likely to be implemented in shared libraries,
> where there is not significant cost to linking the whole thing.  Once you
> have linked to anything at all in the shared library, you've bitten off most
> of the costs.

Well, memory costs are much less than they were in the 1950's.
Even so, the older Fortran implementations I know of put all
the conversion routines in one subroutine.

(There are people working on getting IBSYS, including the Fortran
compiler, running again.  Maybe also the 704 and 709.)

-- glen

Richard Maine <nospam@see.signature> wrote in message news:<m2d63as9t8.fsf@vega.avradionet.com>...

> I think the "read each line into a character variable and then
> parse that" approach is by far the simplest here.

That's true, but all the strings have, in general, different lengths,
and I don't know what's the maximum length of the strings in a file.
Is there anything similar
to STL's 'string' in fortran90, i.e., some data structure for which
the storage can be allocated at the same time as reading from a file?
Or simply set a limitation on string lengths in a file and use a
buffer of the maximum length?

r08n wrote:
> 
> Richard Maine <nospam@see.signature> wrote in message news:<m2d63as9t8.fsf@vega.avradionet.com>...
> 
> > I think the "read each line into a character variable and then
> > parse that" approach is by far the simplest here.
> 
> That's true, but all the strings have, in general, different lengths,
> and I don't know what's the maximum length of the strings in a file.
> Is there anything similar
> to STL's 'string' in fortran90, i.e., some data structure for which
> the storage can be allocated at the same time as reading from a file?
> Or simply set a limitation on string lengths in a file and use a
> buffer of the maximum length?

If you need varying-length strings, there is an implementation of
such a module. It has the problem that it leaks memory, but IIRC
Mart Rentmeester has created a leak-free version (announced in this
group a couple of months back).

What you can do is:

character(len=200) :: string

do 
    read( 10, '(a)', end = 100 ) string

    ... analyse the string

enddo

100 continue
    close(10) 

The read statement will skip to the next line in the file.
There is no chance that lines longer than 200 corrupt 
the memory (as you would risk in C).

Regards,

Arjen

s8ngsu3@yahoo.com (r08n) writes:

> That's true, but all the strings have, in general, different lengths,
> and I don't know what's the maximum length of the strings in a file.
> Is there anything similar
> to STL's 'string' in fortran90, i.e., some data structure for which
> the storage can be allocated at the same time as reading from a file?

There are ways to do that, but it adds extra complication.  I'd judge the
extra complication to be more trouble than it would be worth in this case.
Probably simpler to go with non-advancing reads.  (In fact, you might
end up doing a non-advancing read as part of the implementation of
reading in a variable length string).

> Or simply set a limitation on string lengths in a file and use a
> buffer of the maximum length?

That's what I'd do.  From the structure of your file, it appeared to me
that the maximum record length would probably be quite modest, so you
could use a buffer several times larger than the likely maximum with
negligable cost.  Use 256 or so; if something really might hit 256,
heck go with 4k.  Unless you have some kind of specialized embedded
application, you'll never notice 4k, which is probably more than an
order of magnitude larger than will be needed.

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

Arjen Markus wrote:

<snip>

> If you need varying-length strings, there is an implementation of
> such a module. It has the problem that it leaks memory, but IIRC
> Mart Rentmeester has created a leak-free version (announced in this
> group a couple of months back).
> 

Arjen --

It was actually I who implemented the leak-free strings module; source 
code can be dowloaded from:

http://www.star.ucl.ac.uk/~rhdt/download/fortran/iso_varying_string.f90

This code will work on any F90/F95 compiler which supports ISO/IEC TR 
15581 (allocatable datatype components) -- fortunately, almost all 
recent compilers implement this 'standard' extension.

Best wishes,

Rich Townsend

-- 
Dr Richard H D Townsend
Bartol Research Institute
University of Delaware

[ Delete VOID for valid email address ]

Rich Townsend wrote:
> 
> Arjen Markus wrote:
> 
> <snip>
> 
> > If you need varying-length strings, there is an implementation of
> > such a module. It has the problem that it leaks memory, but IIRC
> > Mart Rentmeester has created a leak-free version (announced in this
> > group a couple of months back).
> >
> 
> Arjen --
> 
> It was actually I who implemented the leak-free strings module; source
> code can be dowloaded from:
> 
> http://www.star.ucl.ac.uk/~rhdt/download/fortran/iso_varying_string.f90
> 

Oh, I do apologize for getting the names wrong. But it provides an 
excellent opportunity to get that version, then.

Regards,

Arjen

This message thread reminds me of discussions in 1996 of "Which is a
better word processor, Word Perfect 5.2 or Word Perfect for Windows
version 6.2?"

The answer in neither. They are both obsolescent languages.

Fortran does have very nice support for arrays with arbritrary
starting index values though.

In article <78f60ba9.0407081037.120794f9@posting.google.com>, Weisberg wrote:
> This message thread reminds me of discussions in 1996 of "Which is a
> better word processor, Word Perfect 5.2 or Word Perfect for Windows
> version 6.2?"

I assume you mean C = WP 5.2 and C++ = WP/win 6.2?

> The answer in neither. They are both obsolescent languages.

I agree, although both (especially C) are very widely used, so IMHO it
can be useful to have at least a working knowledge of C.

To extend your word processor analogy somewhat in the direction of
Fortran; many people still prefer a tool with its roots reaching way
back, namely latex, instead of the supposedly absolutely necessary
latest whizz-bang features of Word 2004 (or whatever the current
version happens to be).


-- 
Janne Blomqvist

Thank you all for suggestions.

Janne Blomqvist <jblomqvi@roskaposti.invalid> wrote in message news:<slrncesfca.kkt.jblomqvi@vipunen.hut.fi>...
> In article <78f60ba9.0407081037.120794f9@posting.google.com>, Weisberg wrote:
> > This message thread reminds me of discussions in 1996 of "Which is a
> > better word processor, Word Perfect 5.2 or Word Perfect for Windows
> > version 6.2?"
> 
> I assume you mean C = WP 5.2 and C++ = WP/win 6.2?
> 
> > The answer in neither. They are both obsolescent languages.
> 
> I agree, although both (especially C) are very widely used, so IMHO it
> can be useful to have at least a working knowledge of C.
> 
> To extend your word processor analogy somewhat in the direction of
> Fortran; many people still prefer a tool with its roots reaching way
> back, namely latex, instead of the supposedly absolutely necessary
> latest whizz-bang features of Word 2004 (or whatever the current
> version happens to be).

OK, but the point is not to discuss about which one is better or not,
but: why modify a language(FORTRAN) to make it able to do the things
in another language's fashion (C/C++)? Why not simply switch?

macruzq@todito.com (Marco A. Cruz Q.) writes:

> OK, but the point is not to discuss about which one is better or not,
> but: why modify a language(FORTRAN) to make it able to do the things
> in another language's fashion (C/C++)? Why not simply switch?

You seem to consistently like these frequently asked provocative
questions.  See google for the old discussions.  In very short:

It is *YOUR* characterization that Fortran is being modified to
do things in a C/C++ fashion.  If you choose to think of it that
way, fine, I won't argue.  Just like I won't argue if you want
to switch.  But don't expect others (such as me) to make decisions
based on your characterization.

I don't think Fortran bears much relationship to C or C++.
I for one, can't stand programming in C/C++.  I find them *VERY*
different from all versions of Fortran.  While you are free to
make your own evaluation of the degree to which new Fortrans are
just imitating C/C++, I'll use my own evaluations in making my
own decision.  If Fortran were to turn into something like C++, then
I wouldn't use either one.

I've heard many people make this "turning into C/C++" comment.
My general impression is that it must be from people with limited
breadth of exposure to programming languages.  For example,
why didn't you comment that it is turning into Ada?  I'd have
thought that a lot closer to the mark.  Still off, but a lot
closer.

I continue to have trouble figuring out whether you are asking
for people to tell you what to do (which I'm not going to do) or
trying to suggest what other people should do (which suggestions
I'm not receptive to either).

If you are asking why other people don't switch, then this is one
reason - they clearly don't make the same evaluation as you do.

If you are asking for someone to tell you why you shouldn't switch,
well... do what you think best, as I said before.

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

"Marco A. Cruz Q." <macruzq@todito.com> wrote in message
news:12796de5.0407091242.30472c85@posting.google.com...
>
> OK, but the point is not to discuss about which one is better or not,
> but: why modify a language(FORTRAN) to make it able to do the things
> in another language's fashion (C/C++)? Why not simply switch?
>

There's no need to switch. Use both, or indeed, with a compliant linker,
throw any other .o(bj)'s into the pot, do multilingual programming and make
the best of each work towards your specific design.

BTW, Sgt. (sic Schulz) Maine is a Fortran terrorist who has
blowed-himself-up-real-good so often as to qualify as a Fortran bunny, who
goes on, and on , and on, ..., you know the type, all ass and no tits but
you can't just shut them up.

-- 
You're Welcome,
Gerry T.
______
"The most successful tyranny is not the one that uses force to assure
uniformity but the one that removes the awareness of other possibilities,
that makes it seem inconceivable that other ways are viable, that removes
the sense that there is an outside." -- Allan Bloom, in The Closing of the
American Mind.

Richard Maine <nospam@see.signature> wrote in message news:<m1r7rk513b.fsf@macfortran.local>...
> macruzq@todito.com (Marco A. Cruz Q.) writes:
> 
> > OK, but the point is not to discuss about which one is better or not,
> > but: why modify a language(FORTRAN) to make it able to do the things
> > in another language's fashion (C/C++)? Why not simply switch?
> 
> You seem to consistently like these frequently asked provocative
> questions.  See google for the old discussions.  In very short:
> 
   As I said before: I do not want flame wars!

> It is *YOUR* characterization that Fortran is being modified to
> do things in a C/C++ fashion.  If you choose to think of it that
> way, fine, I won't argue.  Just like I won't argue if you want
> to switch.  But don't expect others (such as me) to make decisions
> based on your characterization.

  The question comes from the fact of the modifications the FORTRAN
language is undergoing, simply.

> 
> I don't think Fortran bears much relationship to C or C++.
> I for one, can't stand programming in C/C++.  I find them *VERY*
> different from all versions of Fortran.  While you are free to
> make your own evaluation of the degree to which new Fortrans are
> just imitating C/C++, I'll use my own evaluations in making my
> own decision.  If Fortran were to turn into something like C++, then
> I wouldn't use either one.

   Of course, they are different, but it seems that is trying to have
the features already found in another programming languages. And here
comes the question: Why?

> I continue to have trouble figuring out whether you are asking
> for people to tell you what to do (which I'm not going to do) or
> trying to suggest what other people should do (which suggestions
> I'm not receptive to either).

  I do not want that anybody tells me what to do, or even asking why
people are doing what they are doing.

> 
> If you are asking why other people don't switch, then this is one
> reason - they clearly don't make the same evaluation as you do.
> 
> If you are asking for someone to tell you why you shouldn't switch,
> well... do what you think best, as I said before.

  Finally I perceive that the provocative is: YOU ;-)


Regards

Marco A. Cruz Quevedo

On 9 Jul 2004 19:02:00 -0700, macruzq@todito.com (Marco A. Cruz Q.)
wrote:

[snip]
>   Of course, they are different, but it seems that is trying to have
>the features already found in another programming languages. And here
>comes the question: Why?
[snip]

It's good for languages to have some overlap.  Then you can stick to
your favorite language, and not have to mess with a different one just
because you have a task that's not in your favorite's sweet spot.

Ken Plotkin

"Marco A. Cruz Q." wrote:
> 
> Richard Maine <nospam@see.signature> wrote in message news:<m1r7rk513b.fsf@macfortran.local>...
> > macruzq@todito.com (Marco A. Cruz Q.) writes:
> >
> > > OK, but the point is not to discuss about which one is better or not,
> > > but: why modify a language(FORTRAN) to make it able to do the things
> > > in another language's fashion (C/C++)? Why not simply switch?
> >
> > You seem to consistently like these frequently asked provocative
> > questions.  See google for the old discussions.  In very short:
> >
>    As I said before: I do not want flame wars!
> 
> > It is *YOUR* characterization that Fortran is being modified to
> > do things in a C/C++ fashion.  If you choose to think of it that
> > way, fine, I won't argue.  Just like I won't argue if you want
> > to switch.  But don't expect others (such as me) to make decisions
> > based on your characterization.
> 
>   The question comes from the fact of the modifications the FORTRAN
> language is undergoing, simply.
> 
> >
> > I don't think Fortran bears much relationship to C or C++.
> > I for one, can't stand programming in C/C++.  I find them *VERY*
> > different from all versions of Fortran.  While you are free to
> > make your own evaluation of the degree to which new Fortrans are
> > just imitating C/C++, I'll use my own evaluations in making my
> > own decision.  If Fortran were to turn into something like C++, then
> > I wouldn't use either one.
> 
>    Of course, they are different, but it seems that is trying to have
> the features already found in another programming languages. And here
> comes the question: Why?

All languages evolve.  C evolves.  C++ evolves, Ada evolves.  Fortran
evolves.  All languages evolve or they die.  Why should those other
languages be allowed to evolve but not Fortran?  The only real question
is what direction it evolves in.  

-- 

Gary Scott
mailto:garyscott@ev1.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

Why are there two?  God only knows.

Democracy is two wolves and a sheep, voting on what to eat for dinner...
Liberty is a well armed sheep contesting the vote. - Thomas Jefferson

Gerry Thomas wrote:
> 
> parasites) sinecure positions, besides being stagnant and near comatose in
> outlook, are in denial of Fortran's significant shortcoming as relevant to
> the current millennium.

May very well be, however it's one that Fortran shares with all
other languages -- can't write native* Win apps directly in a plain
language. Perhaps you can lay out a blueprint on how that might be
done... but have it patented first.

* Petz' Win95 gruesome rendition of K&R's infamous string doesn't cut
it, neither do any of the interpretive math toys, nor does a plethora of
gui outfitting intermediaries.

Hello,

On Fri, 09 Jul 2004 23:17:01 -0500, "Gary L. Scott"
<garyscott@ev1.net> wrote:

<snip requoted>

>All languages evolve.  C evolves.  C++ evolves, Ada evolves.  Fortran
>evolves.  All languages evolve or they die.  Why should those other
>languages be allowed to evolve but not Fortran?  The only real question
>is what direction it evolves in. =20

Actually, I think C has finished evolving, at least for a while.
I'm not trying to cast C as a dead end, only that
it's reasonably complete for it's intended use (as universal
assembler).  The C standard normative text isn't likely to change
for a while, anyway, if ever.

That also gives the C++ standard a chance to catch up.  :-)

Ada is in the process of the Ada0Y process.

--=20
Cheers!

Dan Nagle
Purple Sage Computing Solutions, Inc.

"Dan Nagle" <dnagle@erols.com> wrote in message
news:7khve05dftm7hq4ono50f6n3hl28nk5890@4ax.com...

> Actually, I think C has finished evolving, at least for a while.
> I'm not trying to cast C as a dead end, only that
> it's reasonably complete for it's intended use (as universal
> assembler).  The C standard normative text isn't likely to change
> for a while, anyway, if ever.

> That also gives the C++ standard a chance to catch up.  :-)

It also takes the heat off Fortran which has degenerated to a DYI language
(F95 + TR's) that has been trying hard (F2003) to assert its relevance in
imitation of C/C++.


-- 
You're Welcome,
Gerry T.
______
"Today's C++ programs will be tomorrow's unmaintainable legacy code." --Ian
Joyner, in a Critique of C++, 3rd ed., 1996.

Dan Nagle wrote:
> 
> Hello,
> 
> On Fri, 09 Jul 2004 23:17:01 -0500, "Gary L. Scott"
> <garyscott@ev1.net> wrote:
> 
> <snip requoted>
> 
> >All languages evolve.  C evolves.  C++ evolves, Ada evolves.  Fortran
> >evolves.  All languages evolve or they die.  Why should those other
> >languages be allowed to evolve but not Fortran?  The only real question
> >is what direction it evolves in.
> 
> Actually, I think C has finished evolving, at least for a while.
> I'm not trying to cast C as a dead end, only that
> it's reasonably complete for it's intended use (as universal
> assembler).  The C standard normative text isn't likely to change
> for a while, anyway, if ever.
> 

Maybe so, but I consider that C evolved into C++ (why else would they
keep the horrid parts).  Saying that C won't evolve further is almost
like saying that Fortran77 won't evolve any further.  I see some here
that seem to be for tweaking Fortran 77 "just a little" just to
standardize free form format or "include" or some other favorite
feature.

> That also gives the C++ standard a chance to catch up.  :-)

Yes, well, if we updated Fortran 77 (FORTRAN 77+) and added a unique
feature, Fortran 2003 would maybe have to catch up also.

> 
> Ada is in the process of the Ada0Y process.

I'm probably the only one that doesn't get this??  (Atta boy seems a
possibility though)

> 
> --
> Cheers!
> 
> Dan Nagle
> Purple Sage Computing Solutions, Inc.


-- 

Gary Scott
mailto:garyscott@ev1.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

Why are there two?  God only knows.

Democracy is two wolves and a sheep, voting on what to eat for dinner...
Liberty is a well armed sheep contesting the vote. - Thomas Jefferson

Gary L. Scott wrote:
....
>> Ada is in the process of the Ada0Y process.
>
> I'm probably the only one that doesn't get this??  (Atta boy seems a
> possibility though)

It's an unknown date.  The present Fortran proposal was
called F200X for a long time.  I suspect that the present
round of Ada was originally called Ada0X and that some
major shakeup happened.  So, they progressed to Ada0Y.
That's a guess without even looking - but based on experience
with how committees work.

-- 
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 wrote:
(snip)

> Actually, I think C has finished evolving, at least for a while.
> I'm not trying to cast C as a dead end, only that
> it's reasonably complete for it's intended use (as universal
> assembler).  The C standard normative text isn't likely to change
> for a while, anyway, if ever.

Well, considering the number of C99 and Fortran2003
compilers that exist, both are some time away from evolving.

(Not that a new standard can't be finished before the previous
one is implemented, but it doesn't happen often.)

-- glen

James Giles wrote:
> 
> Gary L. Scott wrote:
> ...
> >> Ada is in the process of the Ada0Y process.
> >
> > I'm probably the only one that doesn't get this??  (Atta boy seems a
> > possibility though)
> 
> It's an unknown date.  

That was my first guess actually, but "atta-boy" (as in patting
themselves on the back over Ada 95) seemed more likely for some reason
:-)

> The present Fortran proposal was
> called F200X for a long time.  I suspect that the present
> round of Ada was originally called Ada0X and that some
> major shakeup happened.  So, they progressed to Ada0Y.
> That's a guess without even looking - but based on experience
> with how committees work.
> 
> --
> 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


-- 

Gary Scott
mailto:garyscott@ev1.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

Why are there two?  God only knows.

Democracy is two wolves and a sheep, voting on what to eat for dinner...
Liberty is a well armed sheep contesting the vote. - Thomas Jefferson

Marco A. Cruz Q. wrote:
> but: why modify a language(FORTRAN) to make it able to do the things
> in another language's fashion (C/C++)? Why not simply switch?

Equally well you could ask yourself why C99 added complex numbers to
the C language, although Fortran already had them. Why didn't C users
simply switch?

If you think about that for a moment you'll see that your argument is
quite poor. No mainstream language has ever added any particularly
innovative feature. And that is quite alright, since most of the time
the innovative stuff that comes out of Computer Science turns out to
be not so useful in the real world. That's just how science works.

Mainstream languages have large user bases, implementors etc. to think
about. They can't afford to clutter their languages with stuff that
very few people will find useful, and/or are (almost) impossible to
implement correctly. Not to mention that having multiple different
ways of doing the same thing is not necessarily a good
thing. Orthogonality is nice.

However, once in a while CS comes out with something very useful, and
mainstream computing adopts this concept. Like object orientation, for
instance. Which means that the mainstream languages either adopt this
new way of doing things (usually by copying the feature from another
mainstream language that already implemented said feature
successfully), or they stagnate and die as users move to those
languages that implement the new stuff.

-- 
Janne Blomqvist

Janne Blomqvist wrote:
> Marco A. Cruz Q. wrote:
> 
>>but: why modify a language(FORTRAN) to make it able to do the things
>>in another language's fashion (C/C++)? Why not simply switch?

> Equally well you could ask yourself why C99 added complex numbers to
> the C language, although Fortran already had them. Why didn't C users
> simply switch?

(snip)

> Mainstream languages have large user bases, implementors etc. to think
> about. They can't afford to clutter their languages with stuff that
> very few people will find useful, and/or are (almost) impossible to
> implement correctly. Not to mention that having multiple different
> ways of doing the same thing is not necessarily a good
> thing. Orthogonality is nice.

Somehow that sounds just like Fortran 2003.

I don't know it that well, but it reminds me of it,
anyway.   I don't believe that C99 added quite so many
features as Fortran 2003 did, though in both cases the
compilers are slow in arriving.

-- glen

In article <12796de5.0407091242.30472c85@posting.google.com>, Marco A. 
Cruz Q. <macruzq@todito.com> writes
>Janne Blomqvist <jblomqvi@roskaposti.invalid> wrote in message 
>news:<slrncesfca.kkt.jblomqvi@vipunen.hut.fi>...
>> In article <78f60ba9.0407081037.120794f9@posting.google.com>, Weisberg wrote:
>> > This message thread reminds me of discussions in 1996 of "Which is a
>> > better word processor, Word Perfect 5.2 or Word Perfect for Windows
>> > version 6.2?"
>>
>> I assume you mean C = WP 5.2 and C++ = WP/win 6.2?
>>
>> > The answer in neither. They are both obsolescent languages.
>>
>> I agree, although both (especially C) are very widely used, so IMHO it
>> can be useful to have at least a working knowledge of C.
>>
>> To extend your word processor analogy somewhat in the direction of
>> Fortran; many people still prefer a tool with its roots reaching way
>> back, namely latex, instead of the supposedly absolutely necessary
>> latest whizz-bang features of Word 2004 (or whatever the current
>> version happens to be).
>
>OK, but the point is not to discuss about which one is better or not,
>but: why modify a language(FORTRAN) to make it able to do the things
>in another language's fashion (C/C++)? Why not simply switch?

Sometimes you need to do things which are mostly best done in Fortran, 
but one of them exists in C but not Fortran (say). At this point you 
have several options:

a) yes, you can switch. Lots of rewriting already working code, and what 
if something you used in Fortran doesn't exist in C?
b) Mixed language programming. Sometimes a very useful option, but 
linking the two can be complicated, and of course you have to be a 
proficient programmer in both languages.
c) use a modified version of Fortran to add the functionality you need.

For many programmers who just want a little bit of extra functionality, 
c) is much the most practical. Where "modified" means "new standard" 
rather than just vendor specific extensions, you even get portability.

Catherine.
-- 
Catherine Rees Lay
To email me, use my first name in front of the "at".

glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote in message news:<KYqIc.61582$IQ4.32193@attbi_s02>...
 
> Somehow that sounds just like Fortran 2003.
> 
> I don't know it that well, but it reminds me of it,
> anyway.   I don't believe that C99 added quite so many
> features as Fortran 2003 did, though in both cases the
> compilers are slow in arriving.
> 
> -- glen

The Fortran 2003 standard is not yet official, although its contents
are known, so one cannot describe compilers as being "slow in
arriving". I know of no books on C99, about five years after its
adoption, possibly indicating that C99 was stillborn. F2003 already
has the book "Fortran 95/2003 Explained", by Metcalf, Reid and Cohen.
(Ordered it online from Oxford University Press, the book took about 1
week to arrive at my U.S. address and cost about $60 including
shipping).

beliavsky@aol.com wrote:
> I know of no books on C99, about five years after its
> adoption, possibly indicating that C99 was stillborn.

The only remotedly modern C book I have, "C: A Reference Manual, 5th
ed. by Harbison & Steele", does cover the C99 features.

That being said, compiler vendors don't seem to be in any particular
hurry to implement the C99 stuff. I'd guess that by 2008 most Fortran
compilers that are still alive and kicking will implement F2003.


-- 
Janne Blomqvist

Janne Blomqvist wrote:
> 
> beliavsky@aol.com wrote:
> > I know of no books on C99, about five years after its
> > adoption, possibly indicating that C99 was stillborn.
> 
> The only remotedly modern C book I have, "C: A Reference Manual, 5th
> ed. by Harbison & Steele", does cover the C99 features.

Yup.  I highly recommend CARM.  It is the next best thing to the Standard
itself.  Also, to his credit, Harbison has been quite good about keeping
track of errata at http://www.careferencemanual.com.  Not a book for
beginners tho.  

> That being said, compiler vendors don't seem to be in any particular
> hurry to implement the C99 stuff.

A number of vendors (SGI, Intel, IBM, Sun...) compilers are C99 compliant.
So are some of the 3rd party compilers.  Not sure why you guys claim none
exist.

I kinda like C99.  It has finally brought C up to Fortran-66 level in terms
of array handling, and COMPLEX, and LOGICAL data types.  Even to Fortran-77
level - if one ignores the fact that F77 allows user-defined lower bounds on arrays.
Unfortunately, C99 still approaches the restrict/aliasing issue from the wrong
direction.  But I'm not sure the C guys will ever be able to totally fix that.

> I'd guess that by 2008 most Fortran
> compilers that are still alive and kicking will implement F2003.

If history is any guide, it takes 3-5 years after a standard has been
approved for a large number of full implementations to exist.  The
Fortran-2003 proposals are not even an official standard yet.  So 2008
is probably a safe guess.

Walt
-...-
Walt Spector
(w6ws at earthlink dot net)

beliavsky@aol.com wrote:

> glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote in message news:<KYqIc.61582$IQ4.32193@attbi_s02>...

>>Somehow that sounds just like Fortran 2003.

>>I don't know it that well, but it reminds me of it,
>>anyway.   I don't believe that C99 added quite so many
>>features as Fortran 2003 did, though in both cases the
>>compilers are slow in arriving.

> The Fortran 2003 standard is not yet official, although its contents
> are known, so one cannot describe compilers as being "slow in
> arriving". I know of no books on C99, about five years after its
> adoption, possibly indicating that C99 was stillborn. F2003 already
> has the book "Fortran 95/2003 Explained", 

(snip)

Well, I have a book titled something like "Fortran 8x explained",
though we all know that no Fortran standard exists between
77 and 90.   I am still disappointed that they didn't continue
the trend from 66 to 77 to 88.  Trying to describe the fate
of two different standards in one sentence isn't easy.

-- glen

beliavsky@aol.com wrote:
> 
> glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote in message news:<KYqIc.61582$IQ4.32193@attbi_s02>...
> 
> > Somehow that sounds just like Fortran 2003.
> >
> > I don't know it that well, but it reminds me of it,
> > anyway.   I don't believe that C99 added quite so many
> > features as Fortran 2003 did, though in both cases the
> > compilers are slow in arriving.
> >
> > -- glen
> 
> The Fortran 2003 standard is not yet official, although its contents
> are known, so one cannot describe compilers as being "slow in
> arriving". I know of no books on C99, about five years after its
> adoption, possibly indicating that C99 was stillborn. F2003 already
> has the book "Fortran 95/2003 Explained", by Metcalf, Reid and Cohen.
> (Ordered it online from Oxford University Press, the book took about 1
> week to arrive at my U.S. address and cost about $60 including
> shipping).

I ordered mine at B&N.  They told me that it wouldn't be available until
September.
-- 

Gary Scott
mailto:garyscott@ev1.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

Why are there two?  God only knows.

Democracy is two wolves and a sheep, voting on what to eat for dinner...
Liberty is a well armed sheep contesting the vote. - Thomas Jefferson

On Wed, 07 Jul 2004 20:37:41 -0400
Rich Townsend <rhdt@barVOIDtol.udel.edu> wrote:

> Arjen Markus wrote:
> 
> <snip>
> 
> > If you need varying-length strings, there is an implementation of
> > such a module. It has the problem that it leaks memory, but IIRC
> > Mart Rentmeester has created a leak-free version (announced in this
> > group a couple of months back).
> > 
> 
> Arjen --
> 
> It was actually I who implemented the leak-free strings module; source
> 
> code can be dowloaded from:
> 
> http://www.star.ucl.ac.uk/~rhdt/download/fortran/iso_varying_string.f90
> 
> This code will work on any F90/F95 compiler which supports ISO/IEC TR 
> 15581 (allocatable datatype components) -- fortunately, almost all 
> recent compilers implement this 'standard' extension.
> 
> Best wishes,
> 
> Rich Townsend

Actually, there are two non-leaking implementations of
iso_varying_string. Rich Townsend's depends on the TR as he says but
AFAIK implements the standard faithfully.  Mart Rentmeester's does not
depend on the TR but returns variables of type character in some places
where the standard specifies a string. This is mostly not a problem
because assignment is overloaded so you can use a character most places
you expect a string.

David

> 
> -- 
> Dr Richard H D Townsend
> Bartol Research Institute
> University of Delaware
> 
> [ Delete VOID for valid email address ]

David Ham wrote:
> On Wed, 07 Jul 2004 20:37:41 -0400
> Rich Townsend <rhdt@barVOIDtol.udel.edu> wrote:
> 
> 
>>Arjen Markus wrote:
>>
>><snip>
>>
>>>If you need varying-length strings, there is an implementation of
>>>such a module. It has the problem that it leaks memory, but IIRC
>>>Mart Rentmeester has created a leak-free version (announced in this
>>>group a couple of months back).
>>>
>>
>>Arjen --
>>
>>It was actually I who implemented the leak-free strings module; source
>>
>>code can be dowloaded from:
>>
>>http://www.star.ucl.ac.uk/~rhdt/download/fortran/iso_varying_string.f90
>>
>>This code will work on any F90/F95 compiler which supports ISO/IEC TR 
>>15581 (allocatable datatype components) -- fortunately, almost all 
>>recent compilers implement this 'standard' extension.
>>
>>Best wishes,
>>
>>Rich Townsend
> 
> 
> Actually, there are two non-leaking implementations of
> iso_varying_string. Rich Townsend's depends on the TR as he says but
> AFAIK implements the standard faithfully.  Mart Rentmeester's does not
> depend on the TR but returns variables of type character in some places
> where the standard specifies a string. This is mostly not a problem
> because assignment is overloaded so you can use a character most places
> you expect a string.
> 

Ah -- my bad. Thanks for the correction, David.

cheers,

Rich

-- 
Dr Richard H D Townsend
Bartol Research Institute
University of Delaware

[ Delete VOID for valid email address ]