Random@

The following code is confusing me.

When compiled with checkmate win 32, or checkmate win 64 the values returned for x(1) and x(2) are identical.

When compiled with debug win 32, debug win 64, release 32 or release 64 the values for x(1) and x(2) are different.

Which behaviour is correct?

program test
implicit none
real(kind=2) random@
real(kind=2) x1(1:2)
    x1 = 0.d0
    x1 = RANDOM@()
    write(6,*) x1
end program test

Thanks

Ken

I confirmed your results. The /check response looks wrong to me, although is it ? ARRAY = scalar function or ARRAY = elemental function ( if this is possible ?)

What would an ELEMENTAL FUNCTION do with an array argument ?

I used the following in PLATO with different options and got the different response for x1 = RANDOM@()

program test 
   implicit none 
   real(kind=2) random@ 
   real(kind=2) x1(1:2), y1(1:2), z1(1:2) 
   integer i
!
     x1 = 0.d0 
     x1 = RANDOM@() 
     do i = 1,size(y1)
       y1(i) = RANDOM@() 
     end do
     call random_number (z1)
     write(*,*) x1 
     write(*,*) y1 
     write(*,*) z1 

 end program test

I then tried another test on your code

program test 
implicit none 
integer*4, parameter :: n=2  ! try 2 or 3
real(kind=2) random@ 
real(kind=2) x1(1:n) 
    x1 = 0.d0 
    x1 = RANDOM@() 
    write(*,*) x1 
end program test

n=2 reproduces your experience, but n=3 produces the same value for all of x1 for all compile options; /check, /debug or none (release).

What is the correct result now ?

Thanks John, My first thought was that the /debug was incorrect, but then I had some doubts about that. Your modified code has confused me even further.
It will be interesting to read what Paul makes of this.

Ken

Yes I agree. The results are not consistent and ought to be. I will log that this needs fixing. When /CHECK is applied there is only one call to RANDOM@ and this is incorrect. For the time being you will need to use an explicit do loop....

    do i=1,2
      x1(i) = RANDOM@() 
    enddo

Ken,

Using the Fortran intrinsic 'call random_number (x1)' would also give the answer you are expecting, although I do prefer a DO loop approach (using the Fortran intrinsic).

John

I think that FTN95/64 has an incorrect notion of the type of the return value of the built-in non-standard function RANDOM@(). The test code, ks.f90,

program test 
implicit none
double precision random@ 
write(*,'(ES12.4)')random@()
end program test

when run with ftn95 /64 /lgo ks.f90, gives the correct result, 6.7307E-01. With the type declaration of random@ commented out, the output is -1.0025E+26.

Quoted from PaulLaidler

When /CHECK is applied there is only one call to RANDOM@ and this is incorrect.

Here is a counterargument: RANDOM@ is a scalar, non-deterministic function with no arguments. Therefore, the expression in the second assignment statement in the program of the original post is a scalar, and the statement has the form <vector variable> = <scalar expression>. For such an assignment, Fortran requires that the expression should be evaluated only once, and the value copied into every element of the vector variable.

Is this argument incorrect? In what way?

I do seem to have opened up a can of worms here. For 3 decades I have always used (as John suggested) a DO loop for this type of assignment, but I am trying to move with the times. My initial thought was that random@ should be called multiple times - perhaps due to my ingrained serial approach/thinking and this was confirmed by Paul, however Mecej's observation about vector = scalar seems entirely reasonable. I'm still confused as to what is formally 'correct', but know how to overcome the problem. One for us all to be wary of in the future.

Thank you all for your input

Ken

Although

 double precision x1(10)
 ...
 x1 = RANDOM@()
 ...

is syntatically correct, I cannot think of an application where it makes sense. Why would I want to generate a single random number and copy it into an entire array, in any Monte Carlo simulation?

We do need to get the compiler bugs (if any) fixed; as far as your program is concerned, however, I do not think that you should set any array variable equal to the result of RANDOM@() at all.

This bug has now been fixed.

mecej4 is right and /CHECK was giving correct results.

Release mode will be consistent with this in the next release of FTN95.