Fortran - What can be done in FORTRAN that cannot be done in C/C++?

Author

What can be done in FORTRAN that cannot be done in C/C++?

Marco A. Cruz Q.

2004-06-29, 8:57 pm

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

Richard Maine

2004-06-29, 8:57 pm

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

Ken Plotkin

2004-06-29, 8:57 pm

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

Gary L. Scott

2004-06-29, 8:57 pm

"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

E. Robert Tisdale

2004-06-30, 4:01 am

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.

glen herrmannsfeldt

2004-06-30, 4:01 am

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

Gerry Thomas

2004-06-30, 4:01 am

"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:
>
crunching.[color=darkred]
>
> 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.

Gerry Thomas

2004-06-30, 4:01 am

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

Tim Prince

2004-06-30, 4:01 am

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

Gerry Thomas

2004-06-30, 4:01 am

"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...
> ......
> The aliasing rules of C and C++ differ. Using the C anti-aliasing
> facilities in C++ is non-standard.
> 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.

Marco A. Cruz Q.

2004-06-30, 4:01 am

Richard Maine <nospam@see.signature> wrote in message news:<m1vfhayoqq.fsf@macfortran.local>...
> macruzq@todito.com (Marco A. Cruz Q.) writes:
>
>
> 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

James Giles

2004-06-30, 4:01 am

Gerry Thomas wrote:
> "glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
> news:1tpEc.2019$7t3.1384@attbi_s51...
....
>
> 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

Ken Plotkin

2004-06-30, 4:01 am

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

Gerry Thomas

2004-06-30, 4:01 am

"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:
>
>
> [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.

Gerry Thomas

2004-06-30, 4:01 am

"James Giles" <jamesgiles@worldnet.att.net> wrote in message
news:q7rEc.43728$OB3.32202@bgtnsc05-news.ops.worldnet.att.net...
> Gerry Thomas wrote:
> ...
please[color=darkred]
>
> 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.

James Giles

2004-06-30, 4:01 am

Gerry Thomas wrote:
> "James Giles" <jamesgiles@worldnet.att.net> wrote in message
> news:q7rEc.43728$OB3.32202@bgtnsc05-news.ops.worldnet.att.net...
....
>
> 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.

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

James Giles

2004-06-30, 4:01 am

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

E. Robert Tisdale

2004-06-30, 4:01 am

Gerry Thomas wrote:

> James Giles wrote:
>
>
> 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.

glen herrmannsfeldt

2004-06-30, 4:01 am

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

2004-06-30, 4:01 am

"James Giles" <jamesgiles@worldnet.att.net> wrote in message
news:VfsEc.43912$OB3.14332@bgtnsc05-news.ops.worldnet.att.net...
> Gerry Thomas wrote:
> ...
>
> 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[color=darkred]
>
>
> I don't care.

Touché my boy, and I suspect like all of your cru

es, 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.

James Giles

2004-06-30, 4:01 am

Gerry Thomas wrote:
> "James Giles" <jamesgiles@worldnet.att.net> wrote in message
> news:VfsEc.43912$OB3.14332@bgtnsc05-news.ops.worldnet.att.net...
>
> 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

Madhusudan Singh

2004-06-30, 4:01 am

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

2004-06-30, 4:01 am

"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),siz
e(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+1
5),'))'
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

2004-06-30, 4:01 am

"James Giles" <jamesgiles@worldnet.att.net> wrote in message
news:pZsEc.44017$OB3.36553@bgtnsc05-news.ops.worldnet.att.net...
> Gerry Thomas wrote:
>
> 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.

James Giles

2004-06-30, 4:01 am

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

Gerry Thomas

2004-06-30, 4:01 am

"Madhusudan Singh" <spammers-go-here@yahoo.com> wrote in message
news:2kf5f9F1ln8sU1@uni-berlin.de...
> James Giles wrote:
>
>
> 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.

Gerry Thomas

2004-06-30, 4:01 am

"James Giles" <jamesgiles@worldnet.att.net> wrote in message
news:JytEc.163771$Gx4.151639@bgtnsc04-news.ops.worldnet.att.net...
> Gerry Thomas wrote:
whatever[color=darkred]
>
>
> 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.

Jan Vorbrüggen

2004-06-30, 4:01 am

> 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

Jan Vorbrüggen

2004-06-30, 4:01 am

>>There are literally *decades* of papers (CACM, SIGPLAN, etc.)
> 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

Gerry Thomas

2004-06-30, 4:01 am

"Jan Vorbrüggen" <jvorbrueggen-not@mediasec.de> wrote in message
news:2kf87pF1la8rU2@uni-berlin.de...
milestones[color=darkred]
>
> 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

Janne Blomqvist

2004-06-30, 9:05 am

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

Jan Vorbrüggen

2004-06-30, 9:05 am

> 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

Catherine Rees Lay

2004-06-30, 9:05 am

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

Giorgio Pastore

2004-06-30, 9:05 am

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

Dan Tex1

2004-06-30, 3:59 pm

From: "Gerry Thomas" gfthomas@sympatico.ca

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

Once again.... GT is just a little troll with a runny nose. I could care
less if such a fool disagrees with anyone else.

Dan :-)

Richard Maine

2004-06-30, 3:59 pm

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

August Miller

2004-06-30, 3:59 pm

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.

Herman D. Knoble

2004-06-30, 3:59 pm

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

Danguard

2004-06-30, 3:59 pm

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

Danguard

2004-06-30, 3:59 pm

In article <slrnce4t6s.i3j.jblomqvi@vipunen.hut.fi>,
jblomqvi@roskaposti.invalid says...
> Marco A. Cruz Q. wrote:
>
> 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

Janne Blomqvist

2004-06-30, 3:59 pm

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

Herman D. Knoble

2004-06-30, 3:59 pm

glen herrmannsfeldt

2004-06-30, 3:59 pm

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

Kamaraju Kusumanchi

2004-06-30, 3:59 pm

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

Marco A. Cruz Q.

2004-06-30, 9:00 pm

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

Richard Maine

2004-06-30, 9:00 pm

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

2004-06-30, 9:00 pm

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.

2004-06-30, 9:00 pm

"E. Robert Tisdale" wrote:
>
> 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??

Dr Chaos

2004-06-30, 9:00 pm

Kamaraju Kusumanchi <kk288@cornell.edu> wrote:
> Marco A. Cruz Q. wrote:
>
> 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.

2004-06-30, 9:00 pm

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

Gerry Thomas

2004-07-01, 3:57 am

"Jan Vorbrüggen" <jvorbrueggen-not@mediasec.de> wrote in message
news:2kfau8F1ivveU1@uni-berlin.de...
>
> 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

r08n

2004-07-01, 8:57 am

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.

beliavsky@aol.com

2004-07-01, 8:57 am

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...howpage&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."

Richard Edgar

2004-07-01, 8:57 am

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

beliavsky@aol.com

2004-07-01, 4:00 pm

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

James Giles

2004-07-01, 4:00 pm

beliavsky@aol.com wrote:
> Richard Maine <nospam@see.signature> wrote in message
> news:<m1vfhayoqq.fsf@macfortran.local>...
>
> <SNIP>
>
>
> (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

Walter Spector

2004-07-01, 4:00 pm

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)

Richard Edgar

2004-07-01, 4:00 pm

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

Richard Maine

2004-07-01, 4:00 pm

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

Dick Hendrickson

2004-07-01, 4:00 pm

Richard Edgar wrote:
> Walter Spector wrote:
>
>
>
> 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

PetitTrot

2004-07-01, 4:00 pm

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

Gary L. Scott

2004-07-01, 8:58 pm

Richard Maine wrote:
>
> Richard Edgar <rge21@astro.su.se> writes:
>
>
> 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

James Giles

2004-07-02, 3:56 am

Gary L. Scott wrote:
> Richard Maine wrote:
....
>
> 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

Aidan

2004-07-02, 3:56 am

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<