For Programmers: Free Programming Magazines  


Home > Archive > Fortran > December 2004 > Cloning allocatable arrays in F95?









You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

 

Author Cloning allocatable arrays in F95?
Harald Anlauf

2004-12-13, 8:57 am

Hi,

while trying to clone an allocatable array, I found that ALLOCATE
appears to miss a useful feature. It would be nice if the allocate-
shape-specification could also be an integer array of Rank 1. Example:

! a, b, c have deferred shape
real, allocatable, dimension(:,:) :: a, b, c
integer :: i(2)

allocate (a(1,1))
print *, "shape(a) =", shape (a)

!allocate (b (shape (a))) ! <- nice to have
allocate (b (size (a,dim=1), size (a,dim=2)))
print *, "shape(b) =", shape (b)

i(:) = shape (a)
!allocate (c(i(1:2))) ! <- nice to have
allocate (c(i(1),i(2)))
print *, "shape(c) =", shape (c)

end


Note that in the allocation of array b the dimension of a is known and
verifyably agrees with that of b. Similarly, the size of i and the
dimension of c.

Has this been considered before, and if it has been rejected, why? Or
am I missing something? (I am aware that non-default lower bounds
cannot be preserved that easily.)

--
Cheers,
-ha
Richard E Maine

2004-12-13, 4:08 pm

Harald Anlauf <anlauf@hep.tu-darmstadt.de> writes:

> It would be nice if the allocate-
> shape-specification could also be an integer array of Rank 1.

.....
> Has this been considered before, and if it has been rejected, why?


In short, yes, it has been considered. In fact, it has been considered
in more generality than that - namely for any context where one
specifies array bounds. Automatic arrays come to mind. And
I even recall something about dealing with lower bounds - that's
certainly doable, perhaps with another such array.

As to why it got rejected, I'm afraid I just don't recall. If you
wanted my best guess, it probably just didn't get enough support.
Enough things get proposed that they can't all be done, and it doesn't
actually take a concrete reason for something to fail. Failure is
almost the default state, with active reason needed for things to
succeed. Even things that most people like wil fail if they don't get
as much support as other things of comparable difficulty that people
like better. This is just generalization, though. I recall seeing
proposals in this area, but I don't recall anything about the votes
on them.

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
glen herrmannsfeldt

2004-12-13, 4:08 pm



Richard E Maine wrote:

> Harald Anlauf <anlauf@hep.tu-darmstadt.de> writes:



(snip)
[color=darkred]
> In short, yes, it has been considered. In fact, it has been considered
> in more generality than that - namely for any context where one
> specifies array bounds. Automatic arrays come to mind. And
> I even recall something about dealing with lower bounds - that's
> certainly doable, perhaps with another such array.


This is commonly done in C where the only dynamic allocation
method for higher than rank 1 is through arrays of pointers.
It is then easy to allocate the pointed-to arrays any desired
size. There was a discussion before about arrays of pointers
in Fortran, but I don't remember the answer.

-- glen

James Giles

2004-12-13, 9:01 pm

Harald Anlauf wrote:
> Hi,
>
> while trying to clone an allocatable array, I found that ALLOCATE
> appears to miss a useful feature. It would be nice if the allocate-
> shape-specification could also be an integer array of Rank 1. Example:
>
> ! a, b, c have deferred shape
> real, allocatable, dimension(:,:) :: a, b, c
> integer :: i(2)

....
> allocate (a(1,1))

....
> !allocate (b (shape (a))) ! <- nice to have


Or, possibly:

Allocate (b, mold=shape(a))

This follows precedent in the intrinsic functions. And it would
allow several arrays to be allocated withthe same shape based on
one that already exists.

> !allocate (c(i(1:2))) ! <- nice to have



Again, possibly:

Allocate(c, mold=i(1:2))

or, since I is only two elements anyway:

Allocate(c, mold=i)

This kind of addition wouldn't require as much effort as some completely
general way of subscripting arrays with arrays (something which already
has another meaning in some instances - vector subscripts).

--
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


Sponsored Links







Also available: Server administration forum archive | Web Design forum archive | Software forum archive | Hardware reviews archive

Copyright 2008 codecomments.com