Prev: scope of implied do-variable and initialize values
Next: Expressive programming for computational physics in Fortran 95+ (paper)
From: glen herrmannsfeldt on 2 Jun 2010 18:33 Ron Shepard <ron-shepard(a)nospam.comcast.net> wrote: (snip, someone wrote) >> So reals aren't truncated to integers? > No. Actually I can't think of any situation offhand where reals are > truncated to integers. In some contexts, such as mixed arithmetic, > integers are silently converged to reals, but I can't think of any > situations where the reverse occurs. And especially for subprogram > arguments, no conversion is ever done silently, not even between > different kinds of the same type, much less between different types. Well, reals are truncated on assignment to an integer variable, but maybe you don't count that. Some systems allow real expressions for subscripts, truncating the value to an integer. Or course the intrinsic functions specifically designed to convert non-integer values to integers, as appropriate. But yes, it is not done for subroutine arguments. -- glen
From: steve on 2 Jun 2010 19:02 On Jun 2, 3:33 pm, glen herrmannsfeldt <g...(a)ugcs.caltech.edu> wrote: > Ron Shepard <ron-shep...(a)nospam.comcast.net> wrote: > > (snip, someone wrote) > > >> So reals aren't truncated to integers? > > No. Actually I can't think of any situation offhand where reals are > > truncated to integers. In some contexts, such as mixed arithmetic, > > integers are silently converged to reals, but I can't think of any > > situations where the reverse occurs. And especially for subprogram > > arguments, no conversion is ever done silently, not even between > > different kinds of the same type, much less between different types. > > Well, reals are truncated on assignment to an integer variable, > but maybe you don't count that. > > Some systems allow real expressions for subscripts, truncating > the value to an integer. > troutmask:sgk[218] cat > k.f program ohmy real x(3) x = (/ 1, 2, 3 /) print *, x(2.1) end troutmask:sgk[219] gfc4x -o z k.f k.f:4.17: print *, x(2.1) 1 Warning: Extension: REAL array index at (1) troutmask:sgk[220] ./z 2.0000000 -- steve
From: Craig Powers on 3 Jun 2010 20:52 Louis Krupp wrote: > On 6/1/2010 9:40 PM, Ron Shepard wrote: >> In article<5KWdnQAwhvwt9ZjRnZ2dnUVZ_g6dnZ2d(a)indra.net>, >> Louis Krupp<lkrupp_nospam(a)indra.com.invalid> wrote: >> >>> >>> Use modules. The compiler will convert arguments as necessary >> >> No, nothing is converted. >> >>> (someone >>> want to verify this?) >> >> You must be thinking of some other language. Other languages do >> sometimes do silent conversions to match arguments. > > So reals aren't truncated to integers? Certainly not with non-VALUE arguments, but that's true of just about any language I might care to mention; it just becomes obvious with C, C++, etc. because they use value arguments so frequently. Although I don't think there's a strong technical reason for it, it does not appear that Fortran will do any automatic conversion for numeric VALUE arguments. It seems like something that could be put in without an obnoxious amount of effort considering that the text of the '03 standard already says, "If the VALUE attribute is specified, the effect is as if the actual argument is assigned to a temporary, and the temporary is then argument associated with the dummy argument." (But that's in a Note, and the normative text requires that the actual argument be type-compatible with non-pointer, non-allocatable dummy with no qualifications.)
From: Richard Maine on 3 Jun 2010 21:09 Craig Powers <craig.powers(a)invalid.invalid> wrote: > Although I don't think there's a strong technical reason for it, it does > not appear that Fortran will do any automatic conversion for numeric > VALUE arguments. It seems like something that could be put in without > an obnoxious amount of effort... other than completely blowing generics out of the water. :-( And maybe a few other things, but that one immediately occurs to me. Plus, of course, being completely unlike any other procedure arguments in the language, which would be bound to cause no end of confusion. It sure seems a lot simpler and more consistent to just be able to say that arguments must match and there is never any conversion instead of having to add "well, except in this one special class of cases, where it is different just because it could be." -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: Richard Maine on 3 Jun 2010 21:24
Richard Maine <nospam(a)see.signature> wrote: > Craig Powers <craig.powers(a)invalid.invalid> wrote: > > > Although I don't think there's a strong technical reason for it, it does > > not appear that Fortran will do any automatic conversion for numeric > > VALUE arguments. It seems like something that could be put in without > > an obnoxious amount of effort... > > other than completely blowing generics out of the water. :-( > > And maybe a few other things, but that one immediately occurs to me. A related one that occurred to me right after posting that is all the stuff about how procedure resolution works. Admitedly, that is related in that generics get all tied up with it. But I'd call it an additional complication because it would still need work even if one came up with some rule to make it compatible with generics. In fact, any such rule would have to be stuck right in the middle of the the procedure name resolution stuff. That's one of the messier few pages of the standard. The only reason it doesn't generate zillions of questions here is that almost all of the cases in real programs are dead trivial; when you call a procedure by name, there is usually only one accessible procedure with that name and that's the one you get. Anything that touches those particular messy pages counts as a pretty obnoxious amount of effort in my book. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain |