What can be done in FORTRAN that cannot be done in C/C++?
Marco A. Cruz Q.
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
> 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
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
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:gary...@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
> 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
> 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
"E. Robert Tisdale" <E.Robert...@jpl.nasa.gov> wrote in message
news:cbt63g$cfr$1...@nntp1.jpl.nasa.gov...
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
"glen herrmannsfeldt" <g...@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!) ?
Tim Prince
> 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.
facilities in C++ is non-standard.
> Some people find on or the other more readable.
>
that has some influence on the lack of adoption in C++.
Gerry Thomas
"Tim Prince" <tpr...@computer.org> wrote in message
news:P_pEc.79460$cB2....@newssvr29.news.prodigy.com...
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.
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
> "glen herrmannsfeldt" <g...@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
Ken Plotkin
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
"Ken Plotkin" <kplo...@nospam-cox.net> wrote in message
news:5rg4e0purgomhh2db...@4ax.com...
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
"James Giles" <james...@worldnet.att.net> wrote in message
news:q7rEc.43728$OB3....@bgtnsc05-news.ops.worldnet.att.net...
> Gerry Thomas wrote:
> > "glen herrmannsfeldt" <g...@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.
______
James Giles
> "James Giles" <james...@worldnet.att.net> wrote in message
> news:q7rEc.43728$OB3....@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?
James Giles
> "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.
E. Robert Tisdale
> 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.
glen herrmannsfeldt
(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
> Gerry Thomas wrote:
> > "James Giles" <james...@worldnet.att.net> wrote in message
> > news:q7rEc.43728$OB3....@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.
James Giles
> "James Giles" <james...@worldnet.att.net> wrote in message
> news:VfsEc.43912$OB3....@bgtnsc05-news.ops.worldnet.att.net...
>> Gerry Thomas wrote:
>>> "James Giles" <james...@worldnet.att.net> wrote in message
>>> news:q7rEc.43728$OB3....@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.
James Van Buskirk
news:12796de5.04062...@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
> Gerry Thomas wrote:
> > "James Giles" <james...@worldnet.att.net> wrote in message
> > news:VfsEc.43912$OB3....@bgtnsc05-news.ops.worldnet.att.net...
> >> Gerry Thomas wrote:
> >>> "James Giles" <james...@worldnet.att.net> wrote in message
> >>> news:q7rEc.43728$OB3....@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.
James Giles
> 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?
Gerry Thomas
"Madhusudan Singh" <spammers...@yahoo.com> wrote in message
news:2kf5f9F...@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.
> >
>
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
> 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.
Jan Vorbrüggen
> 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
>>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
Gerry Thomas
"Jan Vorbrüggen" <jvorbrue...@mediasec.de> wrote in message
news:2kf87pF...@uni-berlin.de...
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
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
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
Cruz Q. <mac...@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
...
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
>> It *IS* true.
>
>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
> 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
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
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, mac...@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
mac...@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
jblo...@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
Janne Blomqvist
#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
Skip Knoble
On Wed, 30 Jun 2004 06:51:32 GMT, "James Van Buskirk" <not_...@comcast.net> wrote:
-|"Marco A. Cruz Q." <mac...@todito.com> wrote in message
-|news:12796de5.04062...@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.
glen herrmannsfeldt
> 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
>
> I learned programming with FORTRAN, and after several years of
>
> 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.
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?
Richard Maine
> 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.
E. Robert Tisdale
> 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.
bv
>
> > 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??
Dr Chaos
> 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.
bv
>
> double complex z3 = z1*csin(z2);
> fprintf(stdout, "(%lf, %lf) = z1\n", creal(z1), cimag(z1));
>
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
> > 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
r08n
> 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.
beli...@aol.com
> 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要alid
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
> 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
beli...@aol.com
<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
> Richard Maine <nos...@see.signature> wrote in message
> news:<m1vfhay...@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
Walter Spector
> ...
> 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
> 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
> 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.
Dick Hendrickson
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
Also, writing a good program in Fortran is easy.
But with C/C++ you have interest to find programmer with good experience.
"Richard Edgar" <rg...@astro.su.se> wrote in message
news:cc10s9$4fs$1...@news.su.se...
Gary L. Scott
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:gary...@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
> 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.
Aidan
> 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!)
Walter Spector
> ...
> 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...
Jan Vorbrüggen
> 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
> 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
Jan Vorbrüggen
> 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
Arjen Markus
>
>
> 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
Michael Metcalf
> 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-)...
>
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
Richard Edgar
>>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
Richard Edgar
>>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
Gary Scott
> 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?
Gary Scott
> > 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
Walter Spector
>
> > 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 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.
James Giles
...
> 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
Richard Maine
> 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!!!!! :-(
James Giles
> "James Giles" <james...@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?
Ken Plotkin
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
Gib Bogle
> 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
Gib Bogle
> August Miller <ami...@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
Walter Spector
> ...
> 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
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.
Gerry Thomas
"bv" <bv...@Xsdynamix.com> wrote in message
news:40E329ED...@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.
Gerry Thomas
"Walter Spector" <w6ws_xt...@earthlink.net> wrote in message
news:40E58B96...@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.
Gerry Thomas
"Dan Tex1" <dan...@aol.com> wrote in message
news:20040630103715...@mb-m29.aol.com...
> From: "Gerry Thomas" gfth...@sympatico.ca
>
> >> It *IS* true.
> >
> >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 :-)
Desperate Dan is so full of spam, whatever he writes is so full of shite,
that his Mom considers him goddam.
However Dan the Dumb is so much odder, with an intellect so dim as to never
win, that he's worth retaining as fodder.
Pablo
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.
"""
Richard Edgar
> 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
Gary L. Scott
>
> On 2 Jul 2004 07:39:30 -0700, gary.l...@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
Dan Tex1
>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.
--- "anyone with an iota of sense will continue to ignore Fortran" ---
Why is it that those who claim to have a 'higher' intellect and wit often seem
quite incapable of taking their own advice? I wonder why that is? Ignorance
may indeed be bliss.
Dan :-)
Gerry Thomas
Because it's fun thwarting dim wits like you and drooling and dribbling Sgt
(sic Schultz) Maine!, :-(.
beli...@aol.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.
Gerry Thomas
news:3064b51d.04070...@posting.google.com...
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.
Ken Plotkin
[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
James Giles
> 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. :-)
...
> 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.
Dave Weatherall
<gfth...@sympatico.ca> wrote:
Sir
you're pisssing me off.
Plonk
--
Cheers - Dave.
Dave Weatherall
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.
Ken Plotkin
<djw-n...@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.
Richard Maine
> On 3 Jul 2004 14:21:02 -0700, beli...@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
Ken Plotkin
<nos...@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
Dave Weatherall
wrote:
Point taken.
--
Cheers - Dave.
r08n
> 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?