Prev: SuperKISS for 32- and 64-bit RNGs in PL/I.
Next: C interop to popen
From: Richard Maine on 2 Dec 2009 05:50
Ralph Kube <rku000(a)post.uit.no> wrote:

> When i exchange the call in line 81
>
> CALL h5dread_f(dset1_id, H5T_NATIVE_DOUBLE, bufnew, data_dims, error)
>
> with
>
> CALL h5dread_f(dset1_id, H5T_NATIVE_DOUBLE, bufnew, (/64,64/), error)
>
> i get a compiler error:
>
> selectele2.f90(81): error #6285: There is no matching specific
> subroutine for this generic subroutine call. [H5DREAD_F]
> CALL h5dread_f(dset1_id, H5T_NATIVE_DOUBLE, bufnew, (/64,64/), error)
> -----------^
> compilation aborted for selectele2.f90 (code 1)

I'm missing pieces to tell for sure, but this is probably enough to make
at least a decent guess. In particular, let's look at what is different
between those two calls. You focussed on the fact that one uses a
constant where the other uses a variable, but that's not the only
difference, and I doubt it is the important one.

You declare data_dims as

> INTEGER(HSIZE_T), DIMENSION(2) :: data_dims

Thus it is an integer array of kind hsize_t. On the other hand, (/64,
64/) is an integer array of default kind. I don't know precisely what
value hsize_t has, but I'd venture a guess that it is not the kind value
for default integer.

Generic resolution is not affected by whether the actual argument is a
variable or a constant. But it *IS* affected by the kind. The three key
properties for generic resolution are type, kind, and rank (often
abreviated as TKR). You have a match for the type (integer), and rank
(1), but probably nor for the kind.

You could probably use (/64_hsize_t, 64_hsize_t/) if you really wanted,
but I personally think that awkward. There are a bunch of other
alternatives. Your variable would be one. If you want to keep it as a
constant, you could use a named constant (aka parameter) as in

integer(hsize_t), parameter :: data_dims(2) = (/64, 64/)

The compiler will convert the kind for you here, just like it probably
converted the kind when you did

> data_dims(1) = 64
> data_dims(2) = 64

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
From: Ralph Kube on 2 Dec 2009 06:54
Yep, you are right. It runs fine when I pass (/64_hsize_t, 64_hsize_t/)
to the function, thanks a lot.

Richard Maine wrote:
> Ralph Kube <rku000(a)post.uit.no> wrote:
>
>> When i exchange the call in line 81
>>
>> CALL h5dread_f(dset1_id, H5T_NATIVE_DOUBLE, bufnew, data_dims, error)
>>
>> with
>>
>> CALL h5dread_f(dset1_id, H5T_NATIVE_DOUBLE, bufnew, (/64,64/), error)
>>
>> i get a compiler error:
>>
>> selectele2.f90(81): error #6285: There is no matching specific
>> subroutine for this generic subroutine call. [H5DREAD_F]
>> CALL h5dread_f(dset1_id, H5T_NATIVE_DOUBLE, bufnew, (/64,64/), error)
>> -----------^
>> compilation aborted for selectele2.f90 (code 1)
>
> I'm missing pieces to tell for sure, but this is probably enough to make
> at least a decent guess. In particular, let's look at what is different
> between those two calls. You focussed on the fact that one uses a
> constant where the other uses a variable, but that's not the only
> difference, and I doubt it is the important one.
>
> You declare data_dims as
>
>> INTEGER(HSIZE_T), DIMENSION(2) :: data_dims
>
> Thus it is an integer array of kind hsize_t. On the other hand, (/64,
> 64/) is an integer array of default kind. I don't know precisely what
> value hsize_t has, but I'd venture a guess that it is not the kind value
> for default integer.
>
> Generic resolution is not affected by whether the actual argument is a
> variable or a constant. But it *IS* affected by the kind. The three key
> properties for generic resolution are type, kind, and rank (often
> abreviated as TKR). You have a match for the type (integer), and rank
> (1), but probably nor for the kind.
>
> You could probably use (/64_hsize_t, 64_hsize_t/) if you really wanted,
> but I personally think that awkward. There are a bunch of other
> alternatives. Your variable would be one. If you want to keep it as a
> constant, you could use a named constant (aka parameter) as in
>
> integer(hsize_t), parameter :: data_dims(2) = (/64, 64/)
>
> The compiler will convert the kind for you here, just like it probably
> converted the kind when you did
>
>> data_dims(1) = 64
>> data_dims(2) = 64
>
First  |  Prev  | 
Pages: 1 2 3
Prev: SuperKISS for 32- and 64-bit RNGs in PL/I.
Next: C interop to popen