On Tue, 29 Mar 2011, Andres Legarra wrote:
> Hi,
>
> the way I see it is that a guy (actually the compiler) is reading the code.
> In order to know how to allocate
>
> d(k)
>
> he needs to know the value for k.
Yes, but he also needs to know the type and whether it is in a common
or is to be SAVEd. And the order of these statements is not critical.
Cheers, Wes
> Yes, it might be inconvenient. But I also found it logical (and clean) for
> human programmers to know and detail k before d(k).
>
> Cheers
> Andres
>
>
>
>
> Le 29/03/2011 11:17, W.J. Metzger a écrit :
>> Thanks for the reply, However it is not an answer to what I intended to
>> ask. Let me rephrase the question.
>>
>> Type declarations, e.g., DoublePrecision d
>> dimensions, e.g., Dimension d(2)
>> common, common /c/ d
>> can appear in any order. But giving a name to a constant, e.g.,
>> Parameter (k=5)
>> must appear before the first use of the named constant, i.e.,
>> Parameter (k=5, l=2*k)
>> is fine, but
>> Parameter (l=2*k, k=5)
>> is not;
>> Parameter (k=5)
>> Dimension d(k)
>> is fine, but
>> Dimension d(k)
>> Parameter (k=5)
>> is not.
>>
>> I do not understand the logic of this. I was hoping someone would explain
>> this. It seems to me to be contradictory to the lack of a necessary order
>> for type, dimension, common, etc.
>>
>> Cheers, Wes
>>
>>
>> On Mon, 28 Mar 2011, Andrew Chan wrote:
>>
>> > This is because KTMX has not got a value when the statement is
>> > processed. Thank you for your attention.
>> >
>> > Regards,
>> >
>> > Andrew
>> >
>> > --
>> > You cannot change the past but you can improve the future by working on
>> > the present.
>> > --
>> > Eur. Ing. Prof. Andrew H.C. Chan: Professor in Computational Engineering
>> > Deputy UG Admission Tutor, UG Admission day co-ordinator and Overseas UG
>> > Admission Tutor for the School of Civil Engineering
>> > Tel: +44 121 41 45100 Fax: +44 121 41 43675 Mobile: +44 77099 68522
>> > Email: [log in to unmask] or [log in to unmask] webpage MSN
>> > Messenger: [log in to unmask] facebook skype: aquila_eagle twitter:
>> > andrewhcchan Linkedin: [log in to unmask]
>> >
>> > -----Original Message-----
>> > From: Fortran 90 List [mailto:[log in to unmask]] On Behalf
>> > Of W.J. Metzger
>> > Sent: 28 March 2011 13:20
>> > To: [log in to unmask]
>> > Subject: order of statements
>> >
>> > It seems that the order of statements is important in the following,
>> > since both ifort and gfortran give the same error.
>> > But I don't understand why that must be so. Could someone explain?
>> >
>> > This routine gives an error message
>> > Subroutine B (IFL, T, TA)
>> > Integer, Intent(IN) :: IFL
>> > Real, Intent(OUT) :: T(3,KTMX), TA(KTMX)
>> > Integer, Parameter :: KTMX=20
>> > t = ifl
>> > ta = ifl
>> > End Subroutine B
>> >
>> > But the following two variations of it do not
>> > Subroutine G1 (IFL, T, TA)
>> > Integer, Intent(IN) :: IFL
>> > Real, Intent(OUT) :: T, TA
>> > Integer, Parameter :: KTMX=20
>> > Dimension T(3,KTMX), TA(KTMX)
>> > t = ifl
>> > ta = ifl
>> > End Subroutine G1
>> >
>> > Subroutine G2 (IFL, T, TA)
>> > Integer, Parameter :: KTMX=20
>> > Integer, Intent(IN) :: IFL
>> > Real, Intent(OUT) :: T(3,KTMX), TA(KTMX)
>> > t = ifl
>> > ta = ifl
>> > End Subroutine G2
>> >
>> >
>> >
>> > --
>> > Dr. W. J. Metzger Experimental High Energy Physics Group
>> > tel. +31-24-3653127 Faculty of Science
>> > +31-24-3652099 (secr.) Radboud University Nijmegen
>> > fax. +31-24-3652191 Heyendaalseweg 135
>> > 6525 AJ Nijmegen, The Netherlands
>> > e-mail: [log in to unmask] or [log in to unmask]
>> > http://home.cern.ch/metzger/ or http://www.hef.ru.nl/~wes
>>
>
>
--
Dr. W. J. Metzger Experimental High Energy Physics Group
tel. +31-24-3653127 Faculty of Science
+31-24-3652099 (secr.) Radboud University Nijmegen
fax. +31-24-3652191 Heyendaalseweg 135
6525 AJ Nijmegen, The Netherlands
e-mail: [log in to unmask] or [log in to unmask]
http://home.cern.ch/metzger/ or http://www.hef.ru.nl/~wes
|