Fortran - REAL type

Author

REAL type

Thomas Baruchel

2005-12-09, 7:18 pm

Hi,

I have a file computing with real values; I want the user to
quickly customize it to either REAL*8 or REAL*10 (intel) or
REAL*16 (if he/she has it) without changing it everywhere. Thus
he/she would only have to change one initial line at the very
beginning of the file.

What can I do for that purpose ?

--
Thomas Baruchel --- Home Page: http://baruchel.free.fr/~thomas/
write to baruchel at the host called bluebottle dot com
écrire à baruchel chez l'hôte nommé bluebottle point com
(you will be asked for a confirmation the first time you write)

Steven G. Kargl

2005-12-09, 7:18 pm

In article <439a0893$0$29334$626a14ce@news.free.fr>,
Thomas Baruchel <baruchel@127.0.0.1> writes:
> Hi,
>
> I have a file computing with real values; I want the user to
> quickly customize it to either REAL*8 or REAL*10 (intel) or
> REAL*16 (if he/she has it) without changing it everywhere. Thus
> he/she would only have to change one initial line at the very
> beginning of the file.
>
> What can I do for that purpose ?

module types
integer, parameter :: knd = selected_real_kind(p=15,r=300)

end module types

program
use types
real(knd) x
end program

--
Steve
http://troutmask.apl.washington.edu/~kargl/

James Van Buskirk

2005-12-09, 10:09 pm

"Thomas Baruchel" <baruchel@127.0.0.1> wrote in message
news:439a0893$0$29334$626a14ce@news.free.fr...

> I have a file computing with real values; I want the user to
> quickly customize it to either REAL*8 or REAL*10 (intel) or
> REAL*16 (if he/she has it) without changing it everywhere. Thus
> he/she would only have to change one initial line at the very
> beginning of the file.

> What can I do for that purpose ?

The user need not change even a single line of the file.
See module mykinds in
http://home.comcast.net/~kmbtib/rf16.f90
which sets up a kind type parameter (qp) to be that of
REAL*16 if available and REAL*8 if not. If your intent
is to switch between known available kind type parameters,
then generic programming would be a better approach. I've
got a couple of examples of that:
http://home.comcast.net/~kmbtib/codelets.ZIP
and
http://home.comcast.net/~kmbtib/For...ENERIC_BLAS.ZIP

--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

Rich Townsend

2005-12-09, 10:10 pm

James Van Buskirk wrote:
> "Thomas Baruchel" <baruchel@127.0.0.1> wrote in message
> news:439a0893$0$29334$626a14ce@news.free.fr...
>
>
>
>
>
>
> The user need not change even a single line of the file.
> See module mykinds in
> http://home.comcast.net/~kmbtib/rf16.f90
> which sets up a kind type parameter (qp) to be that of
> REAL*16 if available and REAL*8 if not. If your intent
> is to switch between known available kind type parameters,
> then generic programming would be a better approach. I've
> got a couple of examples of that:
> http://home.comcast.net/~kmbtib/codelets.ZIP
> and
> http://home.comcast.net/~kmbtib/For...ENERIC_BLAS.ZIP
>

The stubling block of such a fallback approach is when you have routines
covering both dp and qp. When qp falls back to dp, there is a problem
disambiguating the two sets of routines, since they become TKR-identical. In
such cases, you need to resort to preprocessing and the like.

cheers,

Rich

Ron Shepard

2005-12-11, 4:10 am

In article <J76dncc63-283QfeRVn-pA@comcast.com>,
"James Van Buskirk" <not_valid@comcast.net> wrote:

> The user need not change even a single line of the file.
> See module mykinds in
> http://home.comcast.net/~kmbtib/rf16.f90
> which sets up a kind type parameter (qp) to be that of
> REAL*16 if available and REAL*8 if not.

Here is the relevant code:

module mykinds
implicit none
integer, parameter :: dp = selected_real_kind(15,300)
integer, parameter :: qp_preferred = selected_real_kind(30,1000)
integer, parameter :: qp =
(1+sign(1,qp_preferred))/2*qp_preferred+ &
(1-sign(1,qp_preferred))/2*dp
integer, parameter :: ik2 = selected_int_kind(4)
integer, parameter :: ik8 = selected_int_kind(18)
end module mykinds

The reason I'm posting is to point out that this does not work as
expected on two compilers that I know of (ABSOFT and XLF on MacOSX).
qp_preferred has a value of -2 for both compilers. The statement

integer, parameter :: qpx = selected_real_kind(30)

results in a value of 16, and maxexponent() reveals a maximum
exponent of 1024 for that real type.

My question is why does the qp_preferred value not work as expected
(I expect it to return the same value as qpx)? Is this a compiler
error, is there some subtlety related to signed exponent ranges or
binary/decimal ranges or something?

$.02 -Ron Shepard

James Van Buskirk

2005-12-11, 4:10 am

"Ron Shepard" <ron-shepard@NOSPAM.comcast.net> wrote in message
news:ron-shepard-D48084.00202811122005@comcast.dca.giganews.com...

> My question is why does the qp_preferred value not work as expected
> (I expect it to return the same value as qpx)? Is this a compiler
> error, is there some subtlety related to signed exponent ranges or
> binary/decimal ranges or something?

The subtlety is that MAXEXPONENT yields the maximum exponent in the
Fortran model, so HUGE(x) is just a little under
RADIX(x)**MAXEXPONENT(x), but the R argument to SELECTED_REAL_KIND
is more closely associated with the value returned by the RANGE
intrinsic: 10**RANGE(x) should be representable by reals of the
kind of x. ISTR that Abosoft uses an quad precision kind that
simply consists of two double-precision numbers where the whole
exponent is stored in the high number, and the exponent of the
low number is variable such that the precision of the number can
vary, even widely if there are a lot of consecutive clear bits or
maybe set bits in the number. My module is intended to detect a
IEEE-754 128-bit kind (Alpha X-float). It is taking a miss on
this kind od real, and it also misses on extended precision.

Does:

program test_ep
implicit none
integer, parameter :: ep = selected_real_kind(4931,18)
real(ep) x

write(*,*) precision(x), range(x)
end program test_ep

print out anything useful (after bug fixes) on FTN95? I would
like to come up with a module that does a better job of
detecting higher precision real kinds, but I don't have access
to a lot of different compilers. I was looking at
http://www.polyhedron.com under Fortran Compiler Comparisons
and Language (for Windows compilers) and although it has a
REAL*n field, it doesn't have a RANGE and PRECISION field
for the biggest kind. Is there a source somewhere that has
this info for Fortran-90+ processors all in one place so that
it would be possible to write if not test a more comprehensive
module?

--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

Dan Nagle

2005-12-11, 8:11 am

Hello,

Yes, the issue is "IEEE" quad vs double-double quad.

make_pm gets this one right,
http://users.erols.com/dnagle/make_pm.html

Note also that the new 754r will most likely specify
a quad real type.

James Van Buskirk wrote:
> "Ron Shepard" <ron-shepard@NOSPAM.comcast.net> wrote in message
> news:ron-shepard-D48084.00202811122005@comcast.dca.giganews.com...
>
>
>
>
> The subtlety is that MAXEXPONENT yields the maximum exponent in the
> Fortran model, so HUGE(x) is just a little under
> RADIX(x)**MAXEXPONENT(x), but the R argument to SELECTED_REAL_KIND
> is more closely associated with the value returned by the RANGE
> intrinsic: 10**RANGE(x) should be representable by reals of the
> kind of x. ISTR that Abosoft uses an quad precision kind that
> simply consists of two double-precision numbers where the whole
> exponent is stored in the high number, and the exponent of the
> low number is variable such that the precision of the number can
> vary, even widely if there are a lot of consecutive clear bits or
> maybe set bits in the number. My module is intended to detect a
> IEEE-754 128-bit kind (Alpha X-float). It is taking a miss on
> this kind od real, and it also misses on extended precision.
>
> Does:
>
> program test_ep
> implicit none
> integer, parameter :: ep = selected_real_kind(4931,18)
> real(ep) x
>
> write(*,*) precision(x), range(x)
> end program test_ep
>
> print out anything useful (after bug fixes) on FTN95? I would
> like to come up with a module that does a better job of
> detecting higher precision real kinds, but I don't have access
> to a lot of different compilers. I was looking at
> http://www.polyhedron.com under Fortran Compiler Comparisons
> and Language (for Windows compilers) and although it has a
> REAL*n field, it doesn't have a RANGE and PRECISION field
> for the biggest kind. Is there a source somewhere that has
> this info for Fortran-90+ processors all in one place so that
> it would be possible to write if not test a more comprehensive
> module?
>

--
Cheers!

Dan Nagle
Purple Sage Computing Solutions, Inc.

James Van Buskirk

2005-12-11, 7:17 pm

"Dan Nagle" <dannagle@verizon.net> wrote in message
news:7%Smf.4501$hB6.3643@trnddc05...

> Yes, the issue is "IEEE" quad vs double-double quad.

> make_pm gets this one right,
> http://users.erols.com/dnagle/make_pm.html

Yes, this looks interesting. The problem my code was trying
to solve is peculiar to this kind of forum: if an example
requires more effort to test than simply compiling a single
file and running the resulting executable, the number of
testers will go down dramatically. A classic example is
TEST_FPU.F90 which has been downloaded and tested an
impressive number of times.

If an example requires invoking a procedure to probe the
set of real kinds, it's clearly going to take more than
one stage to compile, and so its accessibility is greatly
diminished. That is why I wanted a list of possibilities
in current use so that I could just pick and choose
between them in a single-file, single-compile example.

Isn't it possible for a binary and a decimal real kind to
have the same precision and range but still be different?
Would a compiler that implemented decimal real kinds
have to include an optional third argument to
selected_real_kind so that the user could demand decimal
real?

--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

Dan Nagle

2005-12-11, 7:17 pm

Hello,

James Van Buskirk wrote:

<snip>

> Isn't it possible for a binary and a decimal real kind to
> have the same precision and range but still be different?
> Would a compiler that implemented decimal real kinds
> have to include an optional third argument to
> selected_real_kind so that the user could demand decimal
> real?

Yes, see the proposals for the RADIX= keyword
to the selected_real_kind() intrinsic.

--
Cheers!

Dan Nagle
Purple Sage Computing Solutions, Inc.

Sponsored Links