KIND related issues on NAGware f95 v 4.1

Hi

I was porting some of my IFC/sun f95 friendly code over to NAG on an AMD
cluster, and found that I could not compile the following declarations :

integer, parameter :: qp = selected_real_kind(33,3000) ! Quad precision
integer, parameter :: qpc = KIND((1.0_qp,1.0_qp))
REAL(DP), PARAMETER :: EULER=0. 5772156649015328606065120900824024310422
_qp
...

KIND value (-3) does not specify a valid representation method
I initially had

integer, parameter :: qp = KIND(1.0Q0)

which yields errors :

: syntax error
detected at 1.0@Q0
***Invalid item in type declaration

How do I use quad precision variables with NAG ?

Thanks.

Madhusudan Singh wrote:
> Hi
>
>         I was porting some of my IFC/sun f95 friendly code over to NAG on 
an AMD
> cluster, and found that I could not compile the following declarations :
>
> integer, parameter :: qp = selected_real_kind(33,3000) ! Quad precision
> integer, parameter :: qpc = KIND((1.0_qp,1.0_qp))
> REAL(DP), PARAMETER :: EULER=0. 5772156649015328606065120900824024310422
_qp
> ...
>
> KIND value (-3) does not specify a valid representation method
> I initially had
>
> integer, parameter :: qp = KIND(1.0Q0)
>
> which yields errors :
>
> : syntax error
>        detected at 1.0@Q0
> ***Invalid item in type declaration
>
>         How do I use quad precision variables with NAG ?

First question that popped into my head:
Does NAG support quad precision? A quick gander at the polyhedron.com compar
ison
page suggests it does not (whereas Intel does.)

Second question:
Why do you think you need them when you initialise a double precision parame
ter
with a quad precision literal constant? What's wrong with something like:
REAL(DP), PARAMETER :: EULER=0.5772156649015328_DP
?

The second question assumes you're only using quad precision in parameter in
itialisations
which is probably not true, but that's the code you posted.

cheers,

paulv

Paul Van Delst wrote:

Thanks for your response.

> First question that popped into my head:
>    Does NAG support quad precision? A quick gander at the polyhedron.com
>    comparison page suggests it does not (whereas Intel does.)
>

That is odd. I thought that this ought to depend more on the underlying
hardware.

And the page :
http://www.nag.co.uk/nagware/NP/r41_doc/f90_kind.html

seems to suggest that quad *might* be available, though I would have to use
a module for this in some way.

Second, could I presumably use selected_real_kind with lower p and r
values ? What would be the upper limit ?

> Second question:
>    Why do you think you need them when you initialise a double precision
>    parameter with a quad precision literal constant? What's wrong with
>    something like:
>      REAL(DP), PARAMETER :: EULER=0.5772156649015328_DP
>    ?
>
> The second question assumes you're only using quad precision in parameter
> initialisations which is probably not true, but that's the code you
> posted.
>

That is right. Quad precision is being used in one part of my code. EULER is
just being defined as quad as it is used there.

Madhusudan Singh <spammers-go-here@spam.invalid> writes:

> KIND value (-3) does not specify a valid representation method

I suspect it is telling you the truth...

> I initially had
>
> integer, parameter :: qp = KIND(1.0Q0)
>
> which yields errors :

because it isn't standard syntax. The Q exponent letter is
a nonstandard extension from pre-f90 days when there was no
standard way to specify anything other than single or double
precision.

>  How do I use quad precision variables with NAG ?

What leads you to believe that the version you have supports quad
precision? I'm not 100% sure which NAG port you are using.  The
precisions supported should be documented in the stuff that came with
the compiler... lets's see, particularly in the TECHINFO file.  Some
of the NAG ports support 128-bit reals and others don't.  Looks like V
4.2 of the 32-bit Linux version does not; I did't check into the
64-bit versions (though those might not have even gone back to V 4.1,
so maybe that's irrelevant).

If the compiler supports quad precision, then I'm quite confident
that the standard syntax will get it.  Your selected_real_kind looks
at least roughly right to me, but I didn't check the numbers.  You
might try numbers a little lower than the very highest ones you
expect.  Sometimes it is easy to get off by 1 (or 2) in terms of
what you think the number of digits is vs what is appropriate
for selected_real_kind.  So just specify numbers known to be too
big for double precision, but not all the way up to the limit of
what you think quad should give.

If the compiler doesn't support quad precision, no syntax is going
to help.  Your options become something like

1. use a multiple-precision package (portable, but slow, and sometimes
a little awkward).

2. get a compiler that supports quad directly

or

3. use an algorithm that doesn't need it.

I can't judge for you which of those would be more appropriate.

--
Richard Maine                       |  Good judgment comes from experience;
email: my first.last at org.domain  |  experience comes from bad judgment.
org: nasa, domain: gov              |        -- Mark Twain

Madhusudan Singh <spammers-go-here@spam.invalid> writes:

> integer, parameter :: qpc = KIND((1.0_qp,1.0_qp))

Oh. As an aside that I failed to notice in my post of just a minute ago...

The above statement is legal (assuming that qp is a valid kind
parameter for reals), but is a bit pointless.  The standard guarantees
that the kind parameters for complex are the same as those for real.
Thus the above line is a rather long-winded way of saying

integer, parameter :: qpc = qc

as long as qc is a valid real kind parameter.  And if qc isn't a valid
real kind parameter, then it is just a way of getting the compiler to
complain about the fact (but that would have happened soon afterwards
anyway).

--
Richard Maine                       |  Good judgment comes from experience;
email: my first.last at org.domain  |  experience comes from bad judgment.
org: nasa, domain: gov              |        -- Mark Twain

Madhusudan Singh <spammers-go-here@spam.invalid> writes:

> Paul Van Delst wrote: 
>
> That is odd. I thought that this ought to depend more on the underlying
> hardware.

Nope.  This is very much a software question.  hardware can make it
simpler or harder (and thus more or less likely) to support a given
precision, but it is not the absolute determiner.

In practice, single and double precision are almost always something
supported natively by the hardware.  They don't have to be in theory,
but in practice, they will be.  Quad precision is a very different
matter.

In NAG's case in particular, the primary determiner is usually
the underlying C compiler.  For example, note that NAG has 2
ports for Sun Solaris, differering in whether they use GCC
or Sun's C compiler.  Same hardware.  One of those NAG ports
supports 128-bit reals; the other doesn't.

--
Richard Maine                       |  Good judgment comes from experience;
email: my first.last at org.domain  |  experience comes from bad judgment.
org: nasa, domain: gov              |        -- Mark Twain

Madhusudan Singh wrote:
> Paul Van Delst wrote:
>
> Thanks for your response.
>
> 
>
>
> That is odd. I thought that this ought to depend more on the underlying
> hardware.
>
> And the page :
> http://www.nag.co.uk/nagware/NP/r41_doc/f90_kind.html
>
> seems to suggest that quad *might* be available, though I would have to us
e
> a module for this in some way.

"Might" is the operative word, since the site you listed above say "This is 
not available
on all systems" wrt Quad precision kind types.

> Second, could I presumably use selected_real_kind with lower p and r
> values ? What would be the upper limit ?

This is what I use in my Type_Kinds.f90 module:

INTEGER, PARAMETER, PUBLIC  :: Single = SELECTED_REAL_KIND(6)  ! Single prec
ision
INTEGER, PARAMETER, PUBLIC  :: Double = SELECTED_REAL_KIND(15) ! Double prec
ision
INTEGER, PARAMETER, PRIVATE :: Quad_t = SELECTED_REAL_KIND(20) ! Quad precis
ion
INTEGER, PARAMETER, PUBLIC  :: Quad   = ( ( ( 1 + SIGN( 1, Quad_t ) ) / 2 ) 
* Quad_t ) + &
( ( ( 1 - SIGN( 1, Quad_t ) ) / 2 ) * Double )

(the Quad precision gymnastics courtesy of James Van Buskirk)

and I test a partiucular system/compiler using:

PROGRAM Test_Type_Kinds
USE Type_Kinds
IMPLICIT NONE
! -- Output the kind types
WRITE( *, '( /5x, "Kind types: ", &
&/10x, "Byte  integer kind type: ", i5, &
&/10x, "Short integer kind type: ", i5, &
&/10x, "Long  integer kind type: ", i5, &
&/10x, "LLong integer kind type: ", i5, &
&/10x, "Single float  kind type: ", i5, &
&/10x, "Double float  kind type: ", i5, &
&/10x, "Quad   float  kind type: ", i5 )' ) &
Byte, Short, Long, LLong, &
Single, Double, Quad
END PROGRAM Test_Type_Kinds

If the Double and Quad kind types output are the same then Quad isn't availa
ble.

And, as to the value of 20 that I use for "p" in selected_real_kind(), that 
is sort of an
assumption that compilers aren't going to hand me anything *less* than a 16 
byte real if I
specify a precision that a double precision variable can't handle. Obviously
 that's not a
very good assumption (I believe 10-byte floats are relatively common in some
 compilers),
but I use Quad so rarely that it's never been a problem (yet! :o).
 
> That is right. Quad precision is being used in one part of my code. EULER 
is
> just being defined as quad as it is used there.

I'm not sure if you meant "that is right" as in you *are* only using quad pr
ecision in the
parameter initialisation, or that my assumption about that is not true. If i
t's the
latter, then Richard Maine has already posted useful suggestions as to how t
o get around
no native NAG Support for Quad precision.

cheers,

paulv

Madhusudan Singh <spammers-go-here@spam.invalid> writes:

> That is right. Quad precision is being used in one part of my code. EULER 
is
> just being defined as quad as it is used there.

Note that Euler is *NOT* defined as quad in the code you showed.  Namely

> REAL(DP), PARAMETER :: EULER=0. 5772156649015328606065120900824024310422
_qp

The real(DP) bit defines it as of kind DP. The _qp used in the value
does *NOT* change that.  Instead it just means that, after going to
the trouble of writing a quad value, you then tell the compiler to
convert it to double.

That's what Paul was talking about.  (Though I'm not Paul, I'm
quite confident of that.)

--
Richard Maine                       |  Good judgment comes from experience;
email: my first.last at org.domain  |  experience comes from bad judgment.
org: nasa, domain: gov              |        -- Mark Twain

Richard E Maine wrote:

> Madhusudan Singh <spammers-go-here@spam.invalid> writes:
> 
>
> Note that Euler is *NOT* defined as quad in the code you showed.  Namely
> 
>
> The real(DP) bit defines it as of kind DP. The _qp used in the value
> does *NOT* change that.  Instead it just means that, after going to
> the trouble of writing a quad value, you then tell the compiler to
> convert it to double.
>
> That's what Paul was talking about.  (Though I'm not Paul, I'm
> quite confident of that.)
>

I know. Its a typo. My cut and paste was not working, and I had to type it
all in :)

Richard E Maine wrote:

(snip)

> because it isn't standard syntax. The Q exponent letter is
> a nonstandard extension from pre-f90 days when there was no
> standard way to specify anything other than single or double
> precision.

I believe the OS/360 Fortran H extended compiler, supporting
extended precision on the 360/85 and most 370's.  Also,
emulated extended precision (by trapping the illegal
instruction) on other machines.  Somewhere around 1968.

-- glen