Hello. I'm working on a project using the current version of the Fortran compiler and the MKL for the first time in quite a while and trying to come up to speed on random number generation. I'm trying to generate discrete uniform variates using the function virnguniform(). In a sequence of subsequent calls the function returns a value of 0 several times and then it returns a value of 2. I'm having trouble discovering what the value of 2 indicates, a error of some kind I'm assuming. I find the Intel documentation challenging to use effectively and I've been searching through files in the mkl subdirectory within the installation directory, but haven't been able to find where the function return values are defined. Any help would be greatly appreciated!
An update. After a little further investigation, the function virnguniform() is returning a wide range of values. I've tried changing associated variable declarations from integer kind 2, 4, and unspecified, but that isn't making a difference. The random numbers generated always seem plausible (between the min and max), but the return value of the function itself has me stumped. According to documentation
the function should return one of a small number of values such as VSL_ERROR_OK, VSL_STATUS_OK, etc. I still haven't been able to locate the definitions of those parameters.
Thanks in advance for any insights you might have.
Jeff: "I've tried changing associated variable declarations from integer kind 2, 4, and unspecified, but that isn't making a difference."
That is a recipe for failure. The MKL routines must be called with correct arguments, and the compiler will not catch errors if you have not provided interfaces to the MKL calls.
The return values are listed only as symbolic values in the documentation, and the corresponding numerical values are listed in mkl_vsl.f90, which is located in the MKL include directory. For example, VSL_STATUS_OK = 0 and VSL_ERROR_NULL_PTR = -5.
Please post your code using the "</>" button in the toolbar, showing declarations and values of the arguments that you pass to MKL.
I need to back up a step and develop some test code to isolate the source(s) of the problem. Please close this issue for now and I'll post a new inquiry if necessary. Thank you, Jeff.
Here is the signature of routine virnguniform(), from file mkl_vsl.f90, which is in the MKL include directory.
INTEGER FUNCTION virnguniform( method, stream, n, r, a, b ) USE MKL_VSL_TYPE INTEGER,INTENT(IN) :: method TYPE(VSL_STREAM_STATE) :: stream INTEGER,INTENT(IN) :: n INTEGER(KIND=4),INTENT(OUT) :: r(n) INTEGER(KIND=4),INTENT(IN) :: a INTEGER(KIND=4),INTENT(IN) :: b END FUNCTION
Note that, except for n, all the integer-type arguments are of kind 4, which for Intel Fortran is the standard X86/X64 32-bit integer. The argument stream, likewise, contains two integers of kind 4.
As a consequence of this, you can run into problems if you use integers of any other kinds than 4 for any of the actual integer arguments.
Please close this issue for now and I'll post a new inquiry if necessary. Thank you.
>> As per your request we are closing this thread. If you need any additional information, please post a new question as this thread will no longer be monitored by Intel.
Yes, that is the interface included in the file mkl_vsl.90. Like n, the argument method is declared as an integer without kind attribute. The integer arguments of vslnewstream() brng and seed are declared as long long int in mkl_types.h. The return values listed in the documentation of virnguniform() are similarly specified as kind=4 integer parameters in mkl_vsl.90. The motivation for my original post was that vslnewstream() appeared (using Visual Studio and the debugger) to be returning values other than those listed in its documentation and many of the values being returned were not defined as parameters. That apparent behavior stopped abruptly after my original post. I've developed minimal code to call virnguniform() but am unable to replicate the problem. I've experimentally changed the kind attribute of the arguments to vslnewstream() and virnguniform(), one at a time, but virnguniform() only returns 0 (no error). The only interesting finding is that if the argument r(n) is anything other than kind=4, the compiler throws an error. For other parameters it only throws warnings. That may be caused by a setting within the project properties? Anyway, whatever was causing the problem originally, it appears to have resolved in my project and I can't replicate it with minimal test code.