KIND optional argument in transformational intrinsics
James Van Buskirk
of the transformational intrinsics. Also a couple of usages of KIND
were not documented, and gfortran does not yet accept f2008 usage for
the SIZE intrinsic.
C:\gfortran\james\intrinsics\func1>type kind.f90
program test
implicit none
integer, parameter :: ck = kind('A')
integer, parameter :: ik = selected_int_kind(18)
integer i
real x
integer array(1)
i = 42
x = 3.14
array = 13
write(*,*) achar(i,kind=ck) ! KIND works but is not documented
write(*,*) char(i,kind=ck) ! KIND works but is not documented
write(*,*) maxloc(array,kind=ik) ! Consistent with f2003 usage
write(*,*) minloc(array,kind=ik) ! Consistent with f2003 usage
write(*,*) nint(x,kind=ik) ! KIND works but is not documented
write(*,*) shape(array,kind=ik) ! Consistent with f2003 usage
write(*,*) size(ik) ! Consistent with f2008 usage
end program test
C:\gfortran\james\intrinsics\func1>gfortran kind.f90 -okind
kind.f90:15.13:
write(*,*) maxloc(array,kind=ik) ! Consistent with f2003 usage
1
Error: Can't find keyword named 'kind' in call to 'maxloc' at (1)
kind.f90:16.13:
write(*,*) minloc(array,kind=ik) ! Consistent with f2003 usage
1
Error: Can't find keyword named 'kind' in call to 'minloc' at (1)
kind.f90:18.13:
write(*,*) shape(array,kind=ik) ! Consistent with f2003 usage
1
Error: Too many arguments in call to 'shape' at (1)
kind.f90:19.19:
write(*,*) size(ik) ! Consistent with f2008 usage
1
Error: 'array' argument of 'size' intrinsic at (1) must be an array
--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end
FX
> write(*,*) char(i,kind=ck) ! KIND works but is not documented
> write(*,*) maxloc(array,kind=ik) ! Consistent with f2003 usage
> write(*,*) minloc(array,kind=ik) ! Consistent with f2003 usage
> write(*,*) nint(x,kind=ik) ! KIND works but is not documented
> write(*,*) shape(array,kind=ik) ! Consistent with f2003 usage
The "works but not documented" cases are documentation bugs indeed. The
others are just because gfortran is not yet a full F2003 compiler, and
are already known.
--
FX
James Giles
> [...] and gfortran does not yet accept f2008 usage for
> the SIZE intrinsic.
You astonish me. An F95 complier with some f2003
features that doesn't fully support a standard that hasn't
even been approved yet?!? This is unacceptable!
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
James Van Buskirk
news:CZjXj.214613$D_3....@bgtnsc05-news.ops.worldnet.att.net...
> James Van Buskirk wrote:
>> [...] and gfortran does not yet accept f2008 usage for
>> the SIZE intrinsic.
> You astonish me. An F95 complier with some f2003
> features that doesn't fully support a standard that hasn't
> even been approved yet?!? This is unacceptable!
Well, I was hoping that the issues raised in this thread were in the
feasible range. Not supporting KIND optional argument for MAXLOC,
MINLOC, and SHAPE for a compiler that uses nondefault integers for
array indices internally might be considered a bug by some:
C:\gfortran\test\large>gfortran large.f90 -olarge
C:\gfortran\test\large>large
2
1
2
C:\gfortran\test\large>type large.f90
program large
use ISO_C_BINDING
implicit none
integer(C_INT8_T), allocatable :: x(:)
integer(C_SIZE_T) I(1)
allocate(x(4294967298_C_SIZE_T))
x = 0
x(4294967297_C_SIZE_T) = -1
x(4294967298_C_SIZE_T) = 1
I = maxloc(x)
write(*,*) I
I = minloc(x)
write(*,*) I
I = shape(x)
write(*,*) I
end program large
Man, that paged everything out! Also supporting scalar actual
argument for ARRAY argument to SIZE intrinsic doesn't seem that
hard: the compiler already detects the case, so all that would be
left is to check the DIM argument (1 <= DIM <= 0) :) and give the
result as INT(0,KIND).
Thomas Koenig
> Well, I was hoping that the issues raised in this thread were in the
> feasible range. Not supporting KIND optional argument for MAXLOC,
> MINLOC, and SHAPE for a compiler that uses nondefault integers for
> array indices internally might be considered a bug by some:
It is considered a bug (an enhancement-one, though): http://gcc.gnu.org/PR29600
James Van Buskirk
news:UtKdneAOs8GoSrDV...@comcast.com...
> Man, that paged everything out! Also supporting scalar actual
> argument for ARRAY argument to SIZE intrinsic doesn't seem that
> hard: the compiler already detects the case, so all that would be
> left is to check the DIM argument (1 <= DIM <= 0) :) and give the
> result as INT(0,KIND).
Must have paged me out as well. The result should have been
INT(1,KIND) for scalar ARRAY actual argument (I think).
James Giles
> "James Giles" <james...@worldnet.att.net> wrote in message
> news:CZjXj.214613$D_3....@bgtnsc05-news.ops.worldnet.att.net...
>> You astonish me. An F95 complier with some f2003
>> features that doesn't fully support a standard that hasn't
>> even been approved yet?!? This is unacceptable!
Well, I misread your original article. I thought the following
really was some new f2008 usage:
write(*,*) size(ik) ! Consistent with f2008 usage
Turns out that F2008 also requires the initial (non-optional)
argument to SIZE to be an array. You line is simply wrong.
(I thought maybe F2008 was doing this as a way of reporting
the bit- or byte-size of a default integer.)
Now, if your example had said:
write(*,*) size(array,ik) ! Consistent with f2008 usage
Maybe I wouldn't have thought that was so completely absurd.
In any case, it isn't really to be expeced that an implementation
have features from a standard that's not been approved. I would
think that is generally irresponsible. There hasn't even been
a public review yet. Suppose they change the syntax?
James Van Buskirk
> James Van Buskirk wrote:
> Well, I misread your original article. I thought the following
> really was some new f2008 usage:
> write(*,*) size(ik) ! Consistent with f2008 usage
> Turns out that F2008 also requires the initial (non-optional)
> argument to SIZE to be an array. You line is simply wrong.
> (I thought maybe F2008 was doing this as a way of reporting
> the bit- or byte-size of a default integer.)
Am I reading an obsolete draft? In N1723.pdf, section 13.7.155:
"SIZE(ARRAY[, DIM, KIND])
Description. Extent of an array along a specified dimension or
the total number of elements in the array.
Class. Inquiry function.
Arguments.
ARRAY shall be a scalar or array of any type."
So where do I find the more current draft that says this is wrong?
> Now, if your example had said:
> write(*,*) size(array,ik) ! Consistent with f2008 usage
> Maybe I wouldn't have thought that was so completely absurd.
> In any case, it isn't really to be expeced that an implementation
> have features from a standard that's not been approved. I would
> think that is generally irresponsible. There hasn't even been
> a public review yet. Suppose they change the syntax?
gfortran has a lot of stuff: they changed the names of their Bessel
function intrinsics for consistency with f08, also they have
implemented ACOSH, ASINH, ATANH, LOG_GAMMA, GAMMA, ERF, ERFC, and
ERCF_SCALED. Well, partially... There are issues with every one
of these intrinsics. For example they don't have complex versions
of LOG and SQRT even though they are part of the f95 standard.
Sorry, take that back: looking at compiler output, they do have
complex LOG and SQRT; it's just that they cause an abort at runtime
(presumably for the KIND=10 versions) like ABS (for COMPLEX(10))
and SPACING and RRSPACING (for REAL(10)) do.
James Giles
> "James Giles" <james...@worldnet.att.net> wrote in message
> news:kmlXj.214889$D_3.1...@bgtnsc05-news.ops.worldnet.att.net...
>
>> James Van Buskirk wrote:
>
>> Well, I misread your original article. I thought the following
>> really was some new f2008 usage:
>
>> write(*,*) size(ik) ! Consistent with f2008 usage
>
>> Turns out that F2008 also requires the initial (non-optional)
>> argument to SIZE to be an array. You line is simply wrong.
>> (I thought maybe F2008 was doing this as a way of reporting
>> the bit- or byte-size of a default integer.)
>
> Am I reading an obsolete draft? In N1723.pdf, section 13.7.155:
>
> "SIZE(ARRAY[, DIM, KIND]
Looks like the correct description. In what way does SIZE(IK)
match the above syntax diagram? IK is a scalar integer named
constant in your sample program. The first (and only) non-optional
argument to SIZE must be an array.
...
>> Now, if your example had said:
>
>> write(*,*) size(array,ik) ! Consistent with f2008 usage
>
>> Maybe I wouldn't have thought that was so completely absurd.
I see I got it wrong too. It should be SIZE(ARRAY,KIND=IK)).
Of course, if you still insist that SIZE(IK) should be an acceptable
syntax, then maybe my original humor is still applicable.
James Van Buskirk
> James Van Buskirk wrote:
>> "SIZE(ARRAY[, DIM, KIND]
> Looks like the correct description. In what way does SIZE(IK)
> match the above syntax diagram? IK is a scalar integer named
> constant in your sample program. The first (and only) non-optional
> argument to SIZE must be an array.
I observe that you have chosen to omit the passage I quoted that
said in plain terms that you were wrong. It read:
> Arguments.
> ARRAY shall be a scalar or array of any type."
SIZE(ik) matches that description, ik being scalar and scalar
being a member of the set {scalar, array}. Or has the standard
document for the English language changed in the interim?
James Giles
....
>> Arguments.
>> ARRAY shall be a scalar or array of any type."
>
> SIZE(ik) matches that description, ik being scalar and scalar
> being a member of the set {scalar, array}. Or has the standard
> document for the English language changed in the interim?
OK. Even worse. It really *is* something I hope doesn't
get approved.
James Giles
> James Van Buskirk wrote:
> ....
>>> Arguments.
>>> ARRAY shall be a scalar or array of any type."
>>
>> SIZE(ik) matches that description, ik being scalar and scalar
>> being a member of the set {scalar, array}. Or has the standard
>> document for the English language changed in the interim?
>
>
> OK. Even worse. It really *is* something I hope doesn't
> get approved.
The following was just posted to the j3 mailing list which
addresses part of the reason I think the SIZE(aScalar) is a
mistake:
> Is the definition ARRAY argument of the SIZE intrinsic correct?
>
> 13.7.155 says
> "ARRAY shall be a scalar or array of any type"
>
> but all of the discussion and examples only refer to
> case where ARRAY is an array.
>
> The definition in the chapter 2 glossary says
>
> 2.1.101
> size
> of an array, the total number of elements in the array
>
> Which also seems to imply that only arrays have a size.
>
> Dick Hendrickson
The thing is, since SIZE is the number of elements, the definition
of "scalar" states the answer as "one". A scalar always consists
of one element. Still, the definition of SIZE doesn't actually say
*what* should be returned for a scalar argument. That case is, as
Dick pointed out, not described in the paragraph on result values.
(Which is why, in the earlier discussion I thought the case was
prohibited - I went straight to the standard document and read
what results should be generated: and it wasn't mentioned.)
If the answer is always one, why would someone use the intrinsic
in the first place. Are there places in F2008 where you can have
a symbol but be unaware whether it's scalar or not? If not, there
are much clearer ways to write 1.
glen herrmannsfeldt
(snip)
> If the answer is always one, why would someone use the intrinsic
> in the first place. Are there places in F2008 where you can have
> a symbol but be unaware whether it's scalar or not? If not, there
> are much clearer ways to write 1.
In C, sizeof(char) is 1 but sometimes useful, mostly for macros.
I could imagine using the preprocessor (cpp or another) in Fortran
where size might be applied to a scalar. Otherwise, I agree,
just write 1.
-- glen
Dick Hendrickson
with extended polymorphic things sometimes components can be
arrays and sometimes not.
There's some justification for allowing SIZE(SCALAR) and calling
it 1. There's a Note in chapter 2, (just before 2.1.101) that
says the shape of a scalar is a zero-sized rank one array.
If you think of SIZE(arg) as PRODUCT(SHAPE(arg)), then allowing
a scalar and calling the result 1 is reasonable.
On the other hand, we may be just going off on a typo. Lots of
stuff gets rewritten for clarity, and it's easy to make a cut
and paste error. Yes, we should all proofread our stuff and
make sure it's all consistent, but stuff happens.
Dick Hendrickson
Dick Hendrickson
James Giles
...
> On the other hand, we may be just going off on a typo. Lots of
> stuff gets rewritten for clarity, and it's easy to make a cut
> and paste error. Yes, we should all proofread our stuff and
> make sure it's all consistent, but stuff happens.
That's what I've been hoping. That's rather why I originally
pointed out the there's really no reason for a Fortran 95 compiler
which is just starting to include F2003 features to jump the
gun and implement a fairly useless feature from a standard
that hasn't even been approved yet. I was being humorous
at the time because I thought the thing couldn't possibly be
anything but a typo.
Dick Hendrickson
> Dick Hendrickson wrote:
> ...
>> On the other hand, we may be just going off on a typo. Lots of
>> stuff gets rewritten for clarity, and it's easy to make a cut
>> and paste error. Yes, we should all proofread our stuff and
>> make sure it's all consistent, but stuff happens.
>
> That's what I've been hoping. That's rather why I originally
> pointed out the there's really no reason for a Fortran 95 compiler
> which is just starting to include F2003 features to jump the
> gun and implement a fairly useless feature from a standard
> that hasn't even been approved yet. I was being humorous
> at the time because I thought the thing couldn't possibly be
> anything but a typo.
>
some clean-up edits. People with copious free time
should look at paper 07-116r1, which is a rather dense set
of small edits, and make sure there are no other little
errors. ;) It should be fixed in the next draft or so.
Dick Hendrickson
James Van Buskirk
news:slrng2rmjn....@meiner.onlinehome.de...
Thinking about the combinatorial explosion of library routines
problem... What if the library routines all accepted an extra
argument, a conversion routine? Then they could all work in
C_SIZE_T intermediates and when it's time to write out a result
they could do so through the conversion routine that would write
out results of the right size and advance the location counter
for the next write by the correct number of bytes. Branch
prediction to the correct routine should be good in that if DIM
is present and there is a monster result array to write out, all
the outputs will have the same kind. Of course I don't know if
there is some problem if the result is to be assigned to a
discontiguous array or if a temporary is already made in any
case.