parameter initialization expressions
in [Fortran]
|
Prev: buy Tramadol without a prescription overnight shipping
Next: prescription weight loss Xanax, Xanax side effects Xanax hydrochloride, prescription Xanax paypal
From: Richard Maine on 11 Mar 2010 22:55 Luka Djigas <ldigas@___gmail___.com> wrote: > On Thu, 11 Mar 2010 14:32:57 -0800, nospam(a)see.signature (Richard Maine) wrote: > > > > >Anyway, spilt milk aside, the thing to understand is that dp above is > >just an integer parameter. Odds are that it is 8, though that will vary. > >In any case, it is a named parameter for some integer value. That is > >*ALL* it is. The fact that its value was computed using > >selected_real_kind does *NOT* restrict it to being used as a real kind > >parameter. That's the most obviously useful way to use it, but you can > >use it anywhere else that you could use an integer parameter with the > >value 8 (or whatever). > > > > I find this part terribly confusing. Not your answer per se, but the part > about reals and integers. If a parameter is declared as real, shouldn't it > be considered as such even with the dot missing ? The parameter is real. What is not real is the expression that is evaluated to compute the parameter value. That expression in your case was 1_dp/2_dp, which is an integer expression giving zero. *AFTER* that expression is evaluated to give 0, it is converted to a real 0.0d0 as needed for the parameter. It is *EXTREMELY* important to understand on of the most fundamental points of Fortran expression evaluation - that evaluation of an expression does not depend on context. That applies here and to many, many other situations. That's why the "after" that I emphasized above. When the compiler is evaluating 1/2 (I'm dropping the _dp parts as just being distracting here), it does not get to look at how it will be used in order to define what it means. In Fortran 1/2 evaluates to 0. Always. No, it is not a real. It is an integer. Only after the expression has been evaluated to get an integer 0 does the compiler get to look and say "I need a real here, but that's ok as I know how to convert the result." Note my phrase "convert the result". It is only the result that gets converted; the compiler doesn't get to go redefine what everything in the expression means based on knowing that the result is going to later get converted. I also note the aparent confusion of your talking about the parameter having the dot missing. That confuses different concepts. There is no dot in a numeric parameter - ever. The 1_dp/2_dp is not the parameter. Instead, the 1_dp/2_dp is the expression that is evaluated to determine the parameter value. Do not think of a parameter as being like a macro, where the actual text is substituted. It is much more like a compile-time variable. The parameter is (whatever its name was - I don't have it in front of me) and it has the value of a double precision real zero. I apologize if the above seems a bit repetitive. I thought the repetition is slightly different forms might help get one that "clicks" for you. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: baf on 12 Mar 2010 00:00 On 3/11/2010 7:55 PM, Richard Maine wrote: > Luka Djigas<ldigas@___gmail___.com> wrote: > >> On Thu, 11 Mar 2010 14:32:57 -0800, nospam(a)see.signature (Richard Maine) > wrote: >> >>> >>> Anyway, spilt milk aside, the thing to understand is that dp above is >>> just an integer parameter. Odds are that it is 8, though that will vary. >>> In any case, it is a named parameter for some integer value. That is >>> *ALL* it is. The fact that its value was computed using >>> selected_real_kind does *NOT* restrict it to being used as a real kind >>> parameter. That's the most obviously useful way to use it, but you can >>> use it anywhere else that you could use an integer parameter with the >>> value 8 (or whatever). >>> >> >> I find this part terribly confusing. Not your answer per se, but the part >> about reals and integers. If a parameter is declared as real, shouldn't it >> be considered as such even with the dot missing ? > > The parameter is real. What is not real is the expression that is > evaluated to compute the parameter value. That expression in your case > was 1_dp/2_dp, which is an integer expression giving zero. *AFTER* that > expression is evaluated to give 0, it is converted to a real 0.0d0 as > needed for the parameter. > > It is *EXTREMELY* important to understand on of the most fundamental > points of Fortran expression evaluation - that evaluation of an > expression does not depend on context. That applies here and to many, > many other situations. That's why the "after" that I emphasized above. > When the compiler is evaluating 1/2 (I'm dropping the _dp parts as just > being distracting here), it does not get to look at how it will be used > in order to define what it means. In Fortran 1/2 evaluates to 0. Always. > No, it is not a real. It is an integer. Only after the expression has > been evaluated to get an integer 0 does the compiler get to look and say > "I need a real here, but that's ok as I know how to convert the result." > Note my phrase "convert the result". It is only the result that gets > converted; the compiler doesn't get to go redefine what everything in > the expression means based on knowing that the result is going to later > get converted. > > I also note the aparent confusion of your talking about the parameter > having the dot missing. That confuses different concepts. There is no > dot in a numeric parameter - ever. The 1_dp/2_dp is not the parameter. > Instead, the 1_dp/2_dp is the expression that is evaluated to determine > the parameter value. Do not think of a parameter as being like a macro, > where the actual text is substituted. It is much more like a > compile-time variable. The parameter is (whatever its name was - I don't > have it in front of me) and it has the value of a double precision real > zero. > > I apologize if the above seems a bit repetitive. I thought the > repetition is slightly different forms might help get one that "clicks" > for you. > For me, the best part about this episode is a reminder that initialization expressions are treated no differently than those evaluated at runtime, and that kind parameters do not in any way specify the type of the object.
From: m on 12 Mar 2010 05:00 On Mar 12, 6:00 am, baf <b...(a)nowhere.com> wrote: > On 3/11/2010 7:55 PM, Richard Maine wrote: > > > > > Luka Djigas<ldigas@___gmail___.com> wrote: > > >> On Thu, 11 Mar 2010 14:32:57 -0800, nos...(a)see.signature (Richard Maine) > > wrote: > > >>> Anyway, spilt milk aside, the thing to understand is that dp above is > >>> just an integer parameter. Odds are that it is 8, though that will vary. > >>> In any case, it is a named parameter for some integer value. That is > >>> *ALL* it is. The fact that its value was computed using > >>> selected_real_kind does *NOT* restrict it to being used as a real kind > >>> parameter. That's the most obviously useful way to use it, but you can > >>> use it anywhere else that you could use an integer parameter with the > >>> value 8 (or whatever). > > >> I find this part terribly confusing. Not your answer per se, but the part > >> about reals and integers. If a parameter is declared as real, shouldn't it > >> be considered as such even with the dot missing ? > > > The parameter is real. What is not real is the expression that is > > evaluated to compute the parameter value. That expression in your case > > was 1_dp/2_dp, which is an integer expression giving zero. *AFTER* that > > expression is evaluated to give 0, it is converted to a real 0.0d0 as > > needed for the parameter. > > > It is *EXTREMELY* important to understand on of the most fundamental > > points of Fortran expression evaluation - that evaluation of an > > expression does not depend on context. That applies here and to many, > > many other situations. That's why the "after" that I emphasized above. > > When the compiler is evaluating 1/2 (I'm dropping the _dp parts as just > > being distracting here), it does not get to look at how it will be used > > in order to define what it means. In Fortran 1/2 evaluates to 0. Always.. > > No, it is not a real. It is an integer. Only after the expression has > > been evaluated to get an integer 0 does the compiler get to look and say > > "I need a real here, but that's ok as I know how to convert the result." > > Note my phrase "convert the result". It is only the result that gets > > converted; the compiler doesn't get to go redefine what everything in > > the expression means based on knowing that the result is going to later > > get converted. > > > I also note the aparent confusion of your talking about the parameter > > having the dot missing. That confuses different concepts. There is no > > dot in a numeric parameter - ever. The 1_dp/2_dp is not the parameter. > > Instead, the 1_dp/2_dp is the expression that is evaluated to determine > > the parameter value. Do not think of a parameter as being like a macro, > > where the actual text is substituted. It is much more like a > > compile-time variable. The parameter is (whatever its name was - I don't > > have it in front of me) and it has the value of a double precision real > > zero. > > > I apologize if the above seems a bit repetitive. I thought the > > repetition is slightly different forms might help get one that "clicks" > > for you. > > For me, the best part about this episode is a reminder that > initialization expressions are treated no differently than those > evaluated at runtime, and that kind parameters do not in any way specify > the type of the object. Notice that the compiler can help you: gfortran -Wconversion test.f90 -o test test.f90:4.24: real(dp),parameter::a=1_dp,b=2_dp,c=a/b,d=1_dp/2_dp 1 Warning: Conversion from INTEGER(8) to REAL(8) at (1) test.f90:4.31: real(dp),parameter::a=1_dp,b=2_dp,c=a/b,d=1_dp/2_dp 1 Warning: Conversion from INTEGER(8) to REAL(8) at (1) test.f90:4.44: real(dp),parameter::a=1_dp,b=2_dp,c=a/b,d=1_dp/2_dp 1 Warning: Conversion from INTEGER(8) to REAL(8) at (1) Marco
From: glen herrmannsfeldt on 12 Mar 2010 05:41 m <mrestelli(a)gmail.com> wrote: (snip) > Notice that the compiler can help you: > gfortran -Wconversion test.f90 -o test > test.f90:4.24: > real(dp),parameter::a=1_dp,b=2_dp,c=a/b,d=1_dp/2_dp 1 > Warning: Conversion from INTEGER(8) to REAL(8) at (1) > test.f90:4.31: (snip) That helps, but it would be even better for the compiler to detect attempts to use a KIND with the wrong type. It is common, but not required, for the KIND values for INTEGER and REAL to overlap. If they didn't, compilers would immediately detect the use of a SELECTED_REAL_KIND value in an INTEGER context. Presumably this happens rarely enough that there haven't been complaints to compiler writers. -- glen
From: robin on 12 Mar 2010 07:41
"glen herrmannsfeldt" <gah(a)ugcs.caltech.edu> wrote in message news:hnc12d$aev$1(a)naig.caltech.edu... | robin <robin_v(a)bigpond.com> wrote: | (nips) | | > Note also that "a = 1_dp" is not what you think it is. | > Again, here, the 1_dp is an INTEGER constant, not a REAL constant. | | > | real(dp),parameter::a=1_dp,b=2_dp,c=a/b,d=1_dp/2_dp | | Well, a is a PARAMETER and, as the declaration says, is REAL, | with KIND(DP). That's irrelevant. What's relevant is that the constant is an INTEGER. The constant 1_dp is NOT real. It's an INTEGER. |