Re: Merseene Twister -- A New Fortran 95 Implementation
From: Matthew C Roberts (roberts.628_at_nationalchampions.osu.edu)
Date: 01/06/04
- Next message: Herman D. Knoble: "Re: ALLOCATABLE arrays"
- Previous message: Matthew C Roberts: "Re: integer(8) problem with CVF 6.6B"
- In reply to: jelansberry: "Re: Merseene Twister -- A New Fortran 95 Implementation"
- Next in thread: jelansberry: "Re: Merseene Twister -- A New Fortran 95 Implementation"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 06 Jan 2004 16:11:37 GMT
On Mon, 5 Jan 2004 19:56:56 -0500, "jelansberry"
<jelansberry@comcast.net> wrote:
>Scott,
>
> I'm trying to compile mtprng.f90 on a Windows platform with CVF 6.6B.
>
> I'm getting the following compiler error at line 200:
>
John,
The CVF 6.6C update fixes this.
Matt.
> integer(INT64), dimension(0:1), parameter :: mag01 = (/
>0_INT64, -1727483681_INT64 /)
>
>^
> The specific compiler error is:
>
> Error: Each ac-value expression in an array-constructor must have the same
>type and type parameters.
>
> I'm not sure what the problem is here, exactly. It seems to be an issue
>with the value -1727483681_INT64 as an INT64. Any thoughts?
>
>John
>
>"Scott Robert Ladd" <scott@coyotegulch.com> wrote in message
>news:pan.2004.01.05.13.18.23.945802@coyotegulch.com...
>> From the text of my article at:
>>
>> http://www.coyotegulch.com/libcoyote/TwistedRoad/TwistedRoad.html
>>
>> In early 2002, I wrote my first Mersenne Twister in Fortran 95; I had
>> just begun working in Fortran again after a decade-long hiatus. I'd spent
>> most of the 1990s working in C, C++, and Java -- but my career began with
>> Fortran, first on DEC PDP-11 system and later on the VAX. Given the
>> limited options for Fortran employment and the lack of interest by
>> publishers in books about "obsolete" tools, it took parallel programming
>> to bring me back into the Fortran fold.
>>
>> I'm a programming polymath and agnostic; in my opinion, the best tool for
>> the job should be used, based on available expertise and technical
>> considerations. The current trend toward forcing every application into
>> Java or C++ is simply wrong and ignorant; much as I respect and like
>> C-derived languages, they have inherent weaknesses in expressiveness and
>> logic that can't be easily glossed over with fancy coding and extensions.
>> I see no point in writing arcane template code in C++ to accomplish a task
>> that can be described succinctly and efficiently in Fortran 95.
>>
>> Yes, I'm impressed by Fortran 95, and I'll likely write an essay about
>> why it and other languages need to be promoted, used, and preserved for
>> the good of computing in general. However, this article is about the
>> Mersenne Twister, and it is to that topic I return.
>>
>> In the last two years, I've written a lot of Fortran 95, and my
>> understanding of the language has improved. My original implementations
>> suffered several faults, one of which constituted a bug. In terms of
>> limitations, the original module has a single state; the current version
>> employs a state structure to allow the coexistence of multiple generators.
>>
>> Also, my original code lost some precision and may have had other errors
>> due to my poor use of Fortran's signed integers. Fortran 95 specifies a
>> symmetric integer model, where every negative number has a positive
>> counterpart. From a mathematical standpoint, this makes sense -- yet it
>> also renders the smallest negative two's complement value (2b-1) invalid.
>> In Fortran 95, -2,147,483,648 (-231) is not a valid 32-bit integer. The
>> reference implementation of the Mersenne Twister, however, is written in
>> C, which imposes no such restriction (other than to say that abs(-231) is
>> undefined).
>>
>> I was unaware of Fortran's integer model, and blithely implemented a
>> Mersenne Twister using the constant -2147483648. And for over a
>> year-and-a-half, the code worked, with both Intel and Lahey compilers. I
>> note that other Fortran implementations also use such out-of-range values,
>> or they implement special bit manipulation routines.
>>
>> Then I involved myself in the GNU gfortran project; gfortran rejected
>> -2147483648 as invalid. Indeed, the "free-as-in-liberty" compiler was
>> correct, using a strict interpretation of the Fortran 95 Standard (section
>> 13.7, to be precise). Faced with both embarassment and broken code, I
>> reexamined the Mersenne Twister module in detail, and, in the end, largely
>> rewrote it. I modified the code to use a state structure, such that I can
>> use several generators at the same time; I also fixed several stylistic
>> problems, and integrated the code with my forthcoming Hypatia library.
>>
>> I solved the integer range problem by storing the seed components in the
>> lower 32 bits of 64-bit integers. Storing the seed in 312 64-bit elements
>> was not a solution, since I would then have had to work around the invalid
>> constant -263. Nor did I want to implement additional bit manipulation
>> rotuines that obscure the underlying algorithm. In the end, the 64-bit
>> elements merely waste a very few bytes of memory in exchange for
>> algorithmic clarity and simplicity. Performance remains excellent.
>>
>> I'm interesting in hearing what people think of the code. The mtrpng
>> module is one of several that I'm going to be releasing for Fortran 95, so
>> I want to be sure my ducks are in a row before I start them quacking.
>>
>> Thanks.
>>
>> ..Scott
>>
>> --
>> Scott Robert Ladd
>> Coyote Gulch Productions (http://www.coyotegulch.com)
>> Software Invention for High-Performance Computing
>>
>>
>
>
- Next message: Herman D. Knoble: "Re: ALLOCATABLE arrays"
- Previous message: Matthew C Roberts: "Re: integer(8) problem with CVF 6.6B"
- In reply to: jelansberry: "Re: Merseene Twister -- A New Fortran 95 Implementation"
- Next in thread: jelansberry: "Re: Merseene Twister -- A New Fortran 95 Implementation"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|