info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Mixing kinds in intrinsic argument list
82 views
Skip to first unread message
Al Greynolds
Mar 1, 2021, 9:04:54 AM3/1/21
to
I went back and compiled my Fortran-95 application using an old version (8.1 from 2003) of IBM XLF. It complained about about the following
max(0,K)
where K is an integer of a different kind than the default. Neither lf95, gfortran or ifort caught this. Were the rules relaxed with later fortran standards with respect to mixing kinds in an intrinsic argument list? I see it is documented as an extension in gfortran.
Al
max(0,K)
where K is an integer of a different kind than the default. Neither lf95, gfortran or ifort caught this. Were the rules relaxed with later fortran standards with respect to mixing kinds in an intrinsic argument list? I see it is documented as an extension in gfortran.
Al
Al Greynolds
Mar 1, 2021, 9:54:50 AM3/1/21
to
It turns out to be an extension in all the compilers which issue a message if directed to do standard checking. I try not to depend on extensions so this was just a case of sloppy programming on my part.
Al
Al
Arjen Markus
Mar 1, 2021, 11:28:22 AM3/1/21
to
On Monday, March 1, 2021 at 3:54:50 PM UTC+1, Al Greynolds wrote:
> It turns out to be an extension in all the compilers which issue a message if directed to do standard checking. I try not to depend on extensions so this was just a case of sloppy programming on my part.
>
> Al
It is quite easy to make such mistakes and it is a good thing that compilers can catch them. In the case of the maximum function: suppose that the maximum is a value that can not be represented by the left-hand side, just because you happened to use an argument of the wrong kind? Maybe a bit contrived, but still.
> It turns out to be an extension in all the compilers which issue a message if directed to do standard checking. I try not to depend on extensions so this was just a case of sloppy programming on my part.
>
> Al
Regards,
Arjen
gah4
Mar 2, 2021, 9:15:48 AM3/2/21
to
On Monday, March 1, 2021 at 8:28:22 AM UTC-8, arjen.m...@gmail.com wrote:
> On Monday, March 1, 2021 at 3:54:50 PM UTC+1, Al Greynolds wrote:
> > It turns out to be an extension in all the compilers which issue a message if directed to do standard checking.
> > I try not to depend on extensions so this was just a case of sloppy programming on my part.
> On Monday, March 1, 2021 at 3:54:50 PM UTC+1, Al Greynolds wrote:
> > It turns out to be an extension in all the compilers which issue a message if directed to do standard checking.
> > I try not to depend on extensions so this was just a case of sloppy programming on my part.
> It is quite easy to make such mistakes and it is a good thing that compilers can catch them.
> In the case of the maximum function: suppose that the maximum is a value that can not be
> represented by the left-hand side, just because you happened to use an argument of the
> wrong kind? Maybe a bit contrived, but still.
It might have been nice to expand to the largest KIND of the arguments.
> In the case of the maximum function: suppose that the maximum is a value that can not be
> represented by the left-hand side, just because you happened to use an argument of the
> wrong kind? Maybe a bit contrived, but still.
Java requires a cast for all narrowing assignments, or it is a compilation time error.
Yes it is an easy mistake to make in Fortran, and not just with function calls.
Java does them in the order byte < short < int < long < float < double, so you can
still have precision loss (assigning int or long to float) but not magnitude loss.
Also, like C, Java floating point constants default to double without a trailing f,
so some of the precision losing operations in Fortran don't occur.
In the case of Math.max, Java argument rules will expand the narrower one, and then
use the appropriate one. (There are only two argument min and max.)
0 new messages