You have a rank 1 expression on the right hand side. Try using

factors = factors(:,f:f)

Jim Dempsey

Quote:

jimdempseyatthecove wrote:

You have a rank 1 expression on the right hand side. Try using

factors = factors(:,f:f)

Jim Dempsey

This is true, but doesn't 7.4.1.3 of the Fortran 2003 standard suggest that the original code is acceptable (with /standard-semantics)?
22 If variable is an allocated allocatable variable, it is deallocated if expr is an array of different shape
23 or any of the corresponding length type parameter values of variable and expr differ. If variable is or
24 becomes an unallocated allocatable variable, then it is allocated with each deferred type parameter equal
25 to the corresponding type parameters of expr , with the shape of expr , and with each lower bound equal
26 to the corresponding element of LBOUND(expr ).

You can't change the rank this way.

For example, 7.2.1.2 Intrinsic Assignment (F2008) says (bolding mine)

(3) the variable and the expr shall be conformable unless the variable is an allocatable array that has the same rank as expr and is neither a coarray nor a coindexed object

You can change the extents of each bound, but not the number of bounds.

"shape" in the above standard refers to the extent of the bound limits of each of the ranks (dimensions).

>>If B is declared as B(2:4, -3:1), then SHAPE (B) has the value (3, 5).

Two arrays that differ in rank also differ in shape.

Two arrays of same rank but different entent of bound limits differ in shape.

real :: A(10,20), B(30,40), C(200), D(-5:4,-10:9)

SHAPE(A) (10,20)
SHAPE(B) (30,40)
SHAPE(C) (200)
SHAPE(D) (10,20)

Shape of A and D the same

Jim Dempsey

Thanks Steve and Jim. That makes sense because the object would then not match its original declaration in terms of rank if the assignment in the OPs post was allowed.

If I understand correctly, Jim's reply gives you SIZE(factors,2) == 1.

"best" implies some sort of judgement about what's best (speed/code clarity, etc). Out of performance sensitive regions I very much tend to go for clarity, and personally I find the array operation syntax clearer than the possible multiline options that may help the compiler avoid a temporary.

(To be honest - I've not bothered to check whether the compiler does generate a temporary with some of these array syntax idioms, but I did have some stack overflow issues a while back that strongly indicate to me that's exactly what was happening with some of my code. Regardless, F2003 is still quite new compiler wise, so things should only get better, and if clear and concise syntax is obvious to me as a source reader as to the intent of a line of code then its probably not too far a step for it to be clear to an optimiser.)

So for chopping - code as presented by Jim. For growing a 1D array, where I know what the new bit is going to be, I simply do "array = [ array, new_bit ]" (being mindful that if array is a derived type with interesting components, then the compiler has been known to generate interesting code). For rank > 1, or when new_bit is yet to be figured out, I use a temporary allocatable and allocate bigger, copy, then swap:

  allocate(tmp(size(array,1), size(array,2)+extra))

  tmp(:,:size(array,2)) = array

  call move_alloc(tmp, array)

(If the lower bound of array isn't 1 then modifications to the above required.)

But I have been accused of profligacy in the past with respect to things like temporaries, etc. If you do some actual measurements I'd be interested in hearing about them.