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: robin on 11 Mar 2010 18:23 "baf" <baf(a)nowhere.com> wrote in message news:4b995539$0$274$14726298(a)news.sunsite.dk... | Why does the following program produce 0.5 for c and 0 for d? Because you have 1/2, which is integer division. To make it real division, you must have something like 1.0_dp/2.0_dp. But why not just write 0.5_dp? No monkey business there ! 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. | program testdp | implicit none | integer, parameter::dp=selected_real_kind(14) | real(dp),parameter::a=1_dp,b=2_dp,c=a/b,d=1_dp/2_dp | write(*,*)c,d | end program testdp
From: glen herrmannsfeldt on 11 Mar 2010 19:15 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). -- glen
From: Luka Djigas on 11 Mar 2010 21:33 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 ? Kind only takes care of a range and precision (mantissa+exponent). I can't think of a case where this would be useful, instead of just producing hard to spot errors (like the one op exerciced). pp, Luka
From: glen herrmannsfeldt on 11 Mar 2010 22:10 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 ? Yes, a PARAMETER declared REAL has type REAL, even with the dot missing. The usual rules for expressions evaluation still apply, though, in determining the value. REAL A A=5/2 gives A the REAL value 2.0, after converting the INTEGER 2 to REAL. Similarly, REAL, PARAMETER:: B=5/2 gives B the REAL value 2.0 > Kind only takes care of a range and precision (mantissa+exponent). > I can't think of a case where this would be useful, instead > of just producing hard to spot errors (like the one op exerciced). It would be standard conforming to have a disjoint set if KINDs between INTEGER kinds and REAL kinds. That would allow the compiler to catch this error. It seems that many compilers use the size in bytes for the KIND values, except for COMPLEX types. -- glen
From: e p chandler on 11 Mar 2010 22:21
"Luka Djigas" <ldigas@___gmail___.com> wrote in message news:9n9jp5pge81lpmv4qfk810rugdbqupvike(a)4ax.com... > 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 ? But that does not make sense, though I too was confused by the d=1_dp / 2_dp I have learned that the types of operands on the right are not promoted to (or related to) the type of the variable on the left. Instead, 1/2 is truncated to 0 and assigned to d. Suppose for the sake of argument that we want this type of error to be detected. dp is of type integer. Any other integer that evaluates to a valid kind for an integer could be mis-used in the same way without producing an error. Yet "dp" is not bound in any way to type "real". There is no type in Fortran such as "kind_specifier_of_real". Perhaps there should be, but now it's probably too late as that would break existing code unless some *new* inquiry functions were added to the language that returned enumerators of the proper "type". (Sorry about that!) -- e > Kind only takes care of a range and precision (mantissa+exponent). > > I can't think of a case where this would be useful, instead of just > producing hard to spot errors > (like the one op exerciced). > > pp, Luka |