I was wondering if it is possible to use overloaded functions with assumed-size array arguments? Please see the example below, in which
I try to overload the BLAS ddot and sdot functions. Calls to ddot
with the first element of the array as an argument rather than an
array segment (the commented out lines) fail at compile time.
! This doesn't work (fails to compile):
! WRITE(*,*)dot_PRODUCT(dx,dy),ddot(3,dx(1),1,dy(1),1)
! WRITE(*,*)dot_PRODUCT(sx,sy),ddot(3,sx(1),1,sy(1),1)
Is there any
other trick one could use to allow assumed-size arguments to work with overloading?
On Friday, March 11, 2022 at 12:53:29 PM UTC-8, nddtwe...@gmail.com wrote:
I was wondering if it is possible to use overloaded functions with
assumed-size array arguments? Please see the example below, in which
I try to overload the BLAS ddot and sdot functions. Calls to ddot
with the first element of the array as an argument rather than an
array segment (the commented out lines) fail at compile time.
(snip)
! This doesn't work (fails to compile):
! WRITE(*,*)dot_PRODUCT(dx,dy),ddot(3,dx(1),1,dy(1),1)
! WRITE(*,*)dot_PRODUCT(sx,sy),ddot(3,sx(1),1,sy(1),1)
(snip)
Is there any
other trick one could use to allow assumed-size arguments to work with
overloading?
You are allowed to call routines with assumed size dummy arrays,
with an array element actual argument. I suspect that the overload
function resolver doesn't know that. Can you also add overload
interfaces for scalar arguments?
Since you ask for a trick, I am suggesting it, otherwise some will probably suggest that you don't do that.
Also, what are the inx and iny arguments for?
However, I now can't pass array segments to the overloaded ddot.
On Friday, March 11, 2022 at 2:44:12 PM UTC-8, nddtwe...@gmail.com wrote:
(snip)
However, I now can't pass array segments to the overloaded ddot.
Actually, I was thinking you could put in both interfaces, but maybe the compilers are too good to allow that.
If they don't allow it, you could put in two copies with different names, that it would call as appropriate, even though the code was the same.
(Or an ENTRY with a different name, but into the same routine.)
I think I probably need to roll up my sleeves and replace the array
elements with arrays in calls to BLAS & LAPACK routines. But I don't
see why in principle compilers can't cope with overloading of
subprograms with assumed-size array arguments, allowing either array
segments or initial array elements to be given in the calls to the
overloaded subprograms.
On 3/12/22 4:34 AM, Neil wrote:
I think I probably need to roll up my sleeves and replace the array elements with arrays in calls to BLAS & LAPACK routines. But I don't
see why in principle compilers can't cope with overloading of
subprograms with assumed-size array arguments, allowing either array segments or initial array elements to be given in the calls to the overloaded subprograms.
I did not follow exactly what your code examples do, but in general you
DO NOT want to do what you are attempting to do when performance is important. The reason is that when you pass an array section actual
argument to an assumed size dummy argument (or to a subprogram with an implicit interface), the compiler will invoke copy-in/copy-out
semantics. That is because the assumed size array must be contiguous.
The compiler might look ahead and skip making that copy in some cases
when it knows the actual argument is also contiguous, but in other cases
it is not possible for the compiler to know, so it will add the overhead anyway. Or at least it will add overhead to do the checking.
On Friday, March 11, 2022 at 12:53:29 PM UTC-8, nddtwe...@gmail.com wrote:
I was wondering if it is possible to use overloaded functions with assumed-size array arguments? Please see the example below, in which(snip)
I try to overload the BLAS ddot and sdot functions. Calls to ddot
with the first element of the array as an argument rather than an
array segment (the commented out lines) fail at compile time.
! This doesn't work (fails to compile):(snip)
! WRITE(*,*)dot_PRODUCT(dx,dy),ddot(3,dx(1),1,dy(1),1)
! WRITE(*,*)dot_PRODUCT(sx,sy),ddot(3,sx(1),1,sy(1),1)
Is there anyYou are allowed to call routines with assumed size dummy arrays,
other trick one could use to allow assumed-size arguments to work with overloading?
with an array element actual argument. I suspect that the overload
function resolver doesn't know that. Can you also add overload
interfaces for scalar arguments?
I did not follow exactly what your code examples do, but in general you
..
My goal is (I think) straightforward: I would like to be able to
switch easily between double precision and single precision arithmetic
in a Fortran program that uses BLAS and LAPACK (and also MPI). ..
Alternately, with what you're pursuing - "I'm trying to modify a large Fortran code that
features lots of assumed-size BLAS/LAPACK calls" - you could consider full-blown
refactoring and modernization that will pay rich dividends while you much more
"easily switch from double precision arithmetic to single precision arithmetic."
gah4 <ga...@u.washington.edu> wrote:
On Friday, March 11, 2022 at 2:44:12 PM UTC-8, nddtwe...@gmail.com wrote:
However, I now can't pass array segments to the overloaded ddot.
Actually, I was thinking you could put in both interfaces, but maybe the compilers are too good to allow that.
Unfortunately gfortran at least doesn't seem to allow this.
If they don't allow it, you could put in two copies with different names, that it would call as appropriate, even though the code was the same.
(Or an ENTRY with a different name, but into the same routine.)
But that would prevent one using external BLAS and LAPACK libraries
such as OpenBLAS in a straightforward manner (if you mean making a
copy of the BLAS and LAPACK routines and renaming them for
overloading).
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 159 |
Nodes: | 16 (0 / 16) |
Uptime: | 99:37:25 |
Calls: | 3,209 |
Files: | 10,563 |
Messages: | 3,009,786 |