Re: problematic array assignment in double precision (ifort, windows)


Rich Townsend wrote:
mvukovic@xxxxxxxxxxxx wrote:
The following function returns a 3-element vector of cooridnates on a
unit sphere. I use it to generate randomely distributed points on a
sphere.

It works fine when I compile it with a switch /real-size:32. However,
when I use /real-size:64, the vector gets loaded with garbage. I also
tried /align with /real-size:64, but no difference.

This routine lies in a module, but the module header does not contain
any other declarations.

The print statements show the calculation to proceed correctly, until
the last step, when I am loading the vector with the values contained
in cos1,cos2,cos3.

function rn_point_on_sphere()

You should have an 'implicit none' here, to pick up any variable-name typos in
your code.

real,dimension(3)::rn_point_on_sphere
real :: rn_angles(2),x1,x2,cos1,cos2,cos3
real :: one=1. ,two=2.,half=0.5

A suggestion: you might want to add the PARAMETER attribute to your definitions
of one, two and half. This is good defensive programming practice -- if you
inadvertently try to overwrite them elsewhere, the compiler will yell.

!! For uniformly distributed points on a sphere, I picked a method
from:
!! Eric W. Weisstein. "Sphere Point Picking." From MathWorld--A
Wolfram Web Resource.
http://mathworld.wolfram.com/SpherePointPicking.html
DO
call random_number( rn_angles )

How is random_number defined? Does it return 32- or 64-bit reals?

The intrinsic random_number subroutine can take an argument of any REAL
type, and like all other Fortran procedures, cannot change the types of
its arguments. I do not think that calling it with a REAL argument when
using the /real-size:64 switch should be more problematic than calling
other intrinsic procedures with REAL arguments.

.

Relevant Pages