# "40+int(rand(0)*2)+1" shows 67?

## "40+int(rand(0)*2)+1" shows 67?

Dear all,

I have two question about "rand."

(1) Why the code "40+int(rand(0)*2)+1" shows 67? I expect it shows 41 or 42.

(2) Why I need modify the code as below to get my results (i.g. 41 or 42)?

use IFPORT

idfile = 40+int(rand()*2+1)

Thanks all experts.

Michael

17 posts / 0 new
For more complete information about compiler optimizations, see our Optimization Notice.

I get 41 or 42. Can you show a complete program that gets the 67 result?

If I had to guess, it would be that you have an IMPLICIT typing for the letter R that is not REAL(4).

Retired 12/31/2016

Hi Steve,

You are right. There are several subroutines show r as a real number. For example:

real fi (ilg), evap (ilg), r (ilg), zpond (ilg), dt (ilg)

I post several codes that I think they might related for your diagnosing.

program runclass

:

!-----pre-running meteorological data
open(unit=41,file="Met_2003.dat")
open(unit=42,file="Met_2004.dat")

:

!-----randomly choose a pre-run meteorological file in the begining of the year

idfile = 40+int(rand(0)*2)+1 !open file id = 41 or 42

rewind(unit=idfile) !rewinding the file to the first line
print *,iyear,idfile !for checking purpose
endif
& pregrd(i),tagrd(i),uvgrd(i),presgrd(i),qagrd(i)
else
!-----a CR met data
& pregrd(i),tagrd(i),uvgrd(i),presgrd(i),qagrd(i)
endif

I wonder my new modification which is using "use IFPORT"and "idfile = 40+int(rand()*2+1)" will influence the whole calculations, becuase I had some error message showed as below.

kuo-macbook-pro:src cks\$ ./runclass
2002 41
starting year .... 2002
1st soil layer energy balance error @ 2002
1 0 0
soil water balance error @ 2002 1
0 0
snow layer energy balance error @ 2002 8
14 0
snow layer energy balance error @ 2002 35
0 0
snow layer energy balance error @ 2002 63
15 0
ground water balance error @ 2002 63
15 0

Please attach a small (if possible) but complete program that demonstrates the problem. Code fragments don't help.

Retired 12/31/2016

ALWAYS use "IMPLICIT NONE", except for small "jiffy" code, and also use "-warn declarations" to catch places where you forgot the "IMPLICIT NONE".

If you want to be extra strict, you can set \$IFORTCFG to something like ~/.ifortrc, then put "-warn declarations" in that file to always emit missing declaration errors. These are only warnings, so you can still write jiffies with implicit variables if you want to, and just ignore the warnings.

Joe Krahn

Hi steve,

Because it contains several thouthads lines, here is a part of the mian program.

Please have a look at this attachment: main.F90

Thank you.
Michael

The code you posted has the USE IFPORT, which you say fixes the problem. You should be able to come up with a 10-line program that reproduces the bad value - that's what I want to see. Start cutting down what you have to the minimum. Often during this process you'll find an error that led to the bad behavior.

Retired 12/31/2016

Hi Steve, The main program just upload (main.F90 in the post # 5) one min ago. Yes, I'm looking at it. Thanks.

You didn't correctly attach the file. Go back into Add Files, select the file you uploaded and click "Add as attachment".

What you did was get the URL of the link, which doesn't work.

Retired 12/31/2016

This large program depends on a lot of other routines and data files you did not provide. When I strip out all of that and just have the expression, I always get 41 or 42.

Please provide a short (10 line) program that demonstrates the 67 result.

Retired 12/31/2016

Hi Steve,

I upload two files: rand_test.F90 and Makefile

It seems my homemade Makefile causes the problems. Can you please have a look? I have already try different flaging in the Makefile, I have no idea about which Flaging doable. Please advise me.

Thanks,
Michael

kuo-macbook-pro:Desktop cks\$ ifort -O0 -real_size 64 -integer_size 64 -heap-arrays rand_test.F90
kuo-macbook-pro:Desktop cks\$ ./a.out
-9223372036854775768
41
41
41
41
41
41
41
41
41

## Attachments:

AttachmentSize
351 bytes
735 bytes

Thanks - that helps. The problem is -reaL_size 64. Without the USE IFPORT, RAND is not explicitly declared and is "default real" You changed that to REAL(8), but the function returns REAL(4), so the results can be wrong. With the USE IFPORT, RAND is declared and the -real_size 64 won't affect it.

Retired 12/31/2016

Hi Steve,

Are there the other functions particularly I need to concern when I using the -real_size 64? How to you think about my Makefile? Any suggestions?

Thanks,
Michael

You should always be concerned about calling IFPORT functions without USE IFPORT, or about any subroutine or function calls without interface checks.

The best suggestion I can offer you is to add "IMPLICIT NONE" to all your sources, or, failing that, "-warn declarations" which does the same thing. Then you won't be surprised by implicit declarations.

I would recommend the use of the standard intrinsic RANDOM_NUMBER rather than the non-standard RAND, but it is a subroutine and not a function.

Retired 12/31/2016

Thank Steve and Tim so much.

Michael