Assignment of Allocatables of Different Shapes in Fortran [duplicate] - fortran

This question already has an answer here:
Allocatable array valued function. gfortran vs ifort
(1 answer)
Closed 5 years ago.
Please look at the following code:
program test
implicit none
integer, allocatable :: v1(:, :)
integer, allocatable :: v2(:, :)
allocate(v1(2, 4))
allocate(v2(2, 3))
v1(:, :) = reshape([11, 12, 13, 14, 15, 16, 17, 18], [2, 4])
v2(:, :) = reshape([21, 22, 23, 24, 25, 26], [2, 3])
print *, v1
print *, 'shape(v1): ', shape(v1)
print *
print *, v2
print *, 'shape(v2): ', shape(v2)
print *
v2 = v1
print *, v1
print *, 'shape(v1): ', shape(v1)
print *
print *, v2
print *, 'shape(v2): ', shape(v2)
print *
deallocate(v1)
deallocate(v2)
end program test
When I compile it with gfortran, I get the following output:
11 12 13 14 15 16 17 18
shape(v1): 2 4
21 22 23 24 25 26
shape(v2): 2 3
11 12 13 14 15 16 17 18
shape(v1): 2 4
11 12 13 14 15 16 17 18
shape(v2): 2 4
When I compile it with ifort, I get the following output:
11 12 13 14 15 16 17 18
shape(v1): 2 4
21 22 23 24 25 26
shape(v2): 2 3
11 12 13 14 15 16 17 18
shape(v1): 2 4
11 12 13 14 15 16
shape(v2): 2 3
which one is reliable? is there a bug in ifort or in gfortran?
gfortran version 4.8.1
ifort version 14.0.0

By default, ifort before version 17 does not use Fortran 2003 semantics for reallocating an allocatable type on the left side of an assignment. The ifort 15 manual has this to say (for the default norealloc-lhs assumption):
The compiler uses Standard Fortran rules when interpreting assignment statements. The left-hand side is assumed to be allocated with the correct shape to hold the right-hand side. If it is not, incorrect behavior will occur.
To allow the left side of the assignment to be reallocated to the proper shape, compile with the option -assume realloc-lhs. Alternatively you can compile with -standard-semantics to make all assumptions default to compliance with the Fortran 2003 standard, with some Fortran 2008 features.

Related

Passing a subarray to a Fortran subroutine

I have created a Fortran array, say
real, dimension(4, 4) :: A
Being a matrix
1 2 3 4
5 6 7 8
9 10 11 12
13 14 15 16
And I want to pass it to a subroutine in form
call MySoubroutine(A(2,2))
And inside my subroutine get this array and modify some of its elements
real, dimension(:), intent(inout) : A
A(1,1) = 91
A(1, 2) = 92
A(2, 1) = 93
A(2, 2) = 94
So after calling the function in my main program the array A is
1 2 3 4
5 91 92 8
9 93 94 12
13 14 15 16
What is the best an most optimum way to achieve such a behaviour?
In detail my questions are:
Is there a better way of using a subarray inside the subroutine?
How shall I declare the array in the subroutine? I want just to pass a pointer to the first element, so may not know the dimension of the subarray.

how to print a list vertically python

>list1=[1,2,3,4]
>list2=[5,6,7,8]
>list3=[9,10,11,12]
>list4=[13,14,15,16]
>list5=[17,18,19,20]
>lists=[list1,list2,list3,list4,list5
I want to print the following code so that it outputs this way:
4 8 12 16 20
3 7 11 15 19
2 6 10 14 18
sorry didn't knew it ignored new lines:
1 5 9 13 17
Thanks in advance (new to python)
One way you could achieve this is to zip up the reversed lists and simply print all the elements out.
list1=[1,2,3,4]
list2=[5,6,7,8]
list3=[9,10,11,12]
list4=[13,14,15,16]
list5=[17,18,19,20]
for l1, l2, l3, l4, l5 in zip(reversed(list1), reversed(list2), reversed(list3), reversed(list4), reversed(list5)):
print(l1, l2, l3, l4, l5, end=' ')
output
4 8 12 16 20 3 7 11 15 19 2 6 10 14 18 1 5 9 13 17

C++ : For loop not iterating designated number of times (1 iteration less) [closed]

Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 6 years ago.
Improve this question
I have a for loop and a variable C.
The loop begins at 0 and is expected to run C times but actually it runs C-1 times.
Here is my code :
vector<int> v(1000) //Allocated globally
int M, S, C;
cin>>M>>S>>C;
//cout<<M<<" "<<S<<" "<<C;
int fi=0, la=0;
for(int i=0; i<C; i++)
{
int f;
cin>>f;
if(i==0l){ fi = f;}
v[f] = f;
cout<<i<<" "<<f<<" "<<v[f]<<endl;
if(i==C-1){ la = f;}
}
This is my test case -
3 27 16
2
3
5
6
8
9
10
13
14
15
16
19
20
21
22
27
Output by Xcode :
0 2 2
1 3 3
2 5 5
3 6 6
4 8 8
5 9 9
6 10 10
7 13 13
8 14 14
9 15 15
10 16 16
11 19 19
12 20 20
13 21 21
14 22 22
I use Xcode on Mac if it makes a difference.
The variables fi and la are to find the first and the last element of the list.
I want to know what is wrong in my code for the for loop and why is it not iterating C times.
Thanks
Your loop is iterating C times. This is the classic Zero-Based Numbering issue.
Let me explain using your example where C is 16 and a numbered list:
2
3
5
6
8
9
10
13
14
15
16
19
20
21
22
27
So you see your lopp did iterate 16 times. To go from 0 to 16 would have actually been iterating one more time, so 17 times.

Print matrix spirally from any point and using given direction

How can we print given matrix spirally from any point and specified direction?
for example
if given matrix is
21 22 23 24 25
20 7 8 9 10
19 6 1 2 11
18 5 4 3 12
17 16 15 14 13
let current position be pointing to 1 and required direction is clockwise
correct output should be 1 2 3 4 5 6 .... upto 25.
I am looking for logic and code in C or C++

Weird __COUNTER__ behavior on LLVM

I'm trying to understand what could cause this problem because everything seems to be fine but the result seems to point out some sort of buggy behavior.
I have a custom struct defined as:
struct MyStruct {
const u16 index;
...
MyStruct(u16 index) : index(index), ... { }
}
static const MyStruct array[] = {
MyStruct(__COUNTER__,...),
MyStruct(__COUNTER__,...),
MyStruct(__COUNTER__,...)
...
}
Now, if I check the preprocessed file with XCode everything is fine and I get incremental indices as they are supposed to be.
At runtime, instead, what happens is that the index 16 becomes 23 and the successive indices are lowered by one, eg:
real index stored index
0 0
1 1
2 2
3 3
4 4
5 5
6 6
7 7
8 8
9 9
10 10
11 11
12 12
13 13
14 14
15 15
16 23
17 16
18 17
19 18
20 19
This is quite curious, especially because 16 seems to be a specific bound. Compiler is Apple Clang 4.2 (based on LLVM 3.2), on XCode 4.6.