From: glen herrmannsfeldt on
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
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
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
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
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