A question about "kind"?
Author Message
A question about "kind"?

In fortran:

real(kind = kind(0.0e0)) :: a
real(kind = kind(0.0d0)) :: b

In C++:
float   a;
doble b;

Is there different between Fortran and C++? The answer is No.

In Fortran:

real(4) :: a
real(8) :: b

In C++:
float   a;
doble b;

Is there different between Fortran and C++? The answer is Yes in some
cases.

1. I saw somewhere real(kind = kind(0.0e0)) :: a is suitable for
different computers. But why in C++ the same format can use in
different computers? And in Fotran, why we can't use real(4) and
real(8)?

2. Are there any advatages of Fortran with real(kind = kind(0.0e0))
and real(kind = kind(0.0d0))  than C++?

Sat, 03 Jul 2010 23:55:43 GMT
A question about "kind"?

Quote:

> In Fortran:

> real(kind = kind(0.0e0)) :: a
> real(kind = kind(0.0d0)) :: b

> In C++:
> float   a;
> doble b;

> Is there different between Fortran and C++? The answer is No.

> In Fortran:

> real(4) :: a
> real(8) :: b

> In C++:
> float   a;
> doble b;

> Is there different between Fortran and C++? The answer is Yes in some
> cases.

The fortran standard doesn't standardise kind type numbers (and I hope it never does). So,
in using using literal values for the kind values, your code is not portable (does it also
qualify as non-standard?).

Quote:
> 1. I saw somewhere real(kind = kind(0.0e0)) :: a is suitable for
> different computers. But why in C++ the same format can use in
> different computers? And in Fotran, why we can't use real(4) and
> real(8)?

> 2. Are there any advatages of Fortran with real(kind = kind(0.0e0))
> and real(kind = kind(0.0d0))  than C++?

In Fortran you do this:
INTEGER, PARAMETER :: Single = SELECTED_REAL_KIND(6)  ! Single precision
INTEGER, PARAMETER :: Double = SELECTED_REAL_KIND(15) ! Double precision
You do it once. And then you forget about it.

From then on you use them like so:
REAL(Single) :: a
REAL(Double) :: b

So, explain it again: What is the issue here?

cheers,

paulv

Sun, 04 Jul 2010 00:23:19 GMT
A question about "kind"?

Quote:

> 1. I saw somewhere real(kind = kind(0.0e0)) :: a is suitable for
> different computers. But why in C++ the same format can use in
> different computers? And in Fotran, why we can't use real(4) and
> real(8)?

> 2. Are there any advatages of Fortran with real(kind = kind(0.0e0))
> and real(kind = kind(0.0d0))  than C++?

The key to the answers is that the form real(4) etc. is non-standard and can
have different meanings (or even none) on different processors. Thus the
other form has the advantage of being standard and portable. Note, however,
it can be made less 'wordy' by using named constants for the kinds, as in:

integer, parameter ::  sp = kind(0.0e0))
integer, parameter ::  dp = kind(0.0d0))
real(sp) :: a
real(dp) :: b

Aso, if ever you run a machine with a very different word length, you can
control the actual precisions by changing just one or two statements (see
also p. 71 of "Fortran 95/2003 Explained").

HTH,

Mike Metcalf

Sun, 04 Jul 2010 00:25:18 GMT
A question about "kind"?

Quote:
> Is there different between Fortran and C++? The answer is No.

The Fortran kind mechanism allows you to specify the kinds of
literals in a more flexible way than C++.  Look at
http://home.comcast.net/~kmbtib/fft64t.i90 for example. all the
constants are defined to be of kind 'wp' in the subroutine.  When
included in http://home.comcast.net/~kmbtib/fft64t.f90 all the
constants and variables magically have the kind type parameter of
double-precision.  The could just as easily have been made single-
precision or even quad- or extanded-precision.  It's much more
awkward to set the kind type parameters of literals in C++.  You
would probably have to rewrite any expression for every possible
kind type parameter and use preprocessor directives to choose
between them.

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

Sun, 04 Jul 2010 01:03:04 GMT
A question about "kind"?

Quote:

>> 1. I saw somewhere real(kind = kind(0.0e0)) :: a is suitable for
>> different computers. But why in C++ the same format can use in
>> different computers? And in Fotran, why we can't use real(4) and
>> real(8)?

>> 2. Are there any advatages of Fortran with real(kind = kind(0.0e0))
>> and real(kind = kind(0.0d0))  than C++?

> The key to the answers is that the form real(4) etc. is non-standard and can
> have different meanings (or even none) on different processors. Thus the other
> form has the advantage of being standard and portable. Note, however, it can
> be made less 'wordy' by using named constants for the kinds, as in:

> integer, parameter ::  sp = kind(0.0e0))
> integer, parameter ::  dp = kind(0.0d0))
> real(sp) :: a
> real(dp) :: b

> Aso, if ever you run a machine with a very different word length, you can
> control the actual precisions by changing just one or two statements (see also
> p. 71 of "Fortran 95/2003 Explained").

> HTH,
> Mike Metcalf

One minor correction.  The form
Real(4)    :: X
**IS** standard, but it can be non-portable.

A Fortran compiler is allowed to have its own unique list of kind numbers
and the representation method of each.  Although a widely observed custom, it is
not necessary that a Fortran compiler use the kind numbers that correspond to
the number of bytes of storage.  E.g., the Siverfrost (formerly Salford) FTN95
compiler uses kind numbers 1, 2, and 3 for the Intel 32 bit, 64 bit, and 80 bit
reals, respectively.  Most other compilers would use kind numbers 4, 8, and 10.

It is even possible that a Fortran compiler could use different kind numbers
to distinguish different representation methods that use the same amount of
storage.  E.g., if a hardware architecture has both a native format and an IEEE
format for single and double precision reals, a Fortran compiler for that
hardware could use one kind number for the native SP format, a different kind
number for the IEEE SP format, and third and fourth kind numbers for the native
and IEEE DP formats.  AFAIK, no Fortran compiler actually does this, but it is
possible and the standard allows it.

Best solution:  Develop a module of all kind numbers and other processor
dependencies and use that module consistently in every program and procedure.
You can either roll your own or else use Dan Nagle's Make_PM program, which is
available on his web site.

--
Craig Dedo
17130 W. Burleigh Place
P. O. Box 423
Brookfield, WI   53008-0423
Voice:  (262) 783-5869
Fax:    (262) 783-5928
Mobile: (414) 412-5869

Sun, 04 Jul 2010 01:05:32 GMT
A question about "kind"?

Quote:

> > The key to the answers is that the form real(4) etc. is non-standard
>     One minor correction.  The form
>         Real(4)    :: X
> **IS** standard, but it can be non-portable.

If one wants to be that pedantic, the correct answer is that whether it
is standard or not depends on what compiler you are using. Yes, that
seems a bit strange, but that's the way it is. The standard requires
that the kind number be one supported by the processor. Thus, the code
is code is standard-conforming on some compilers, but not on others.

It is probably less mind-contorting to just say something like that the
code is non-portable. That is, after all, the important point. I just
replied because the "correction" didn't seem any more correct than
Michael's original.

--
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain

Sun, 04 Jul 2010 02:07:33 GMT
A question about "kind"?

Quote:

>> > The key to the answers is that the form real(4) etc. is non-standard
>>     One minor correction.  The form
>>         Real(4)    :: X
>> **IS** standard, but it can be non-portable.

> If one wants to be that pedantic, the correct answer is that whether it
> is standard or not depends on what compiler you are using. Yes, that
> seems a bit strange, but that's the way it is. The standard requires
> that the kind number be one supported by the processor. Thus, the code
> is code is standard-conforming on some compilers, but not on others.

> It is probably less mind-contorting to just say something like that the
> code is non-portable. That is, after all, the important point. I just
> replied because the "correction" didn't seem any more correct than
> Michael's original.

> --
> Richard Maine                    | Good judgement comes from experience;
> email: last name at domain . net | experience comes from bad judgement.
> domain: summertriangle           |  -- Mark Twain

I disagree.  The standard explicitly anticipates the use of kind type
parameter values not supported by a processor.  Such kind type parameter values
are standard-conforming, but not supported.

A program is standard-conforming if it uses only those forms and
relationships described in the standard and the program has an interpretation
according to the standard.  Thus, the use of non-supported kind type parameter
values is a form described in the standard and it has an interpretation
according to the standard.

A standard-conforming Fortran compiler is required to report the use of
non-supported kind type parameters.  Section 1.5 says, in part, "A processor
conforms to this standard if . . . (4) It contains the capability to detect and
report the use within a submitted program unit of an intrinsic type with a kind
type parameter value not supported by the processor (4.4);".

Yes, rule R404 together with constraint C404 require the kind type parameter
to have a value supported by the processor.  However, this means that the use
within a program of a non-supported kind type parameter value makes the program
invalid on that particular processor, but such a program is still
standard-conforming.

--
Craig Dedo
17130 W. Burleigh Place
P. O. Box 423
Brookfield, WI   53008-0423
Voice:  (262) 783-5869
Fax:    (262) 783-5928
Mobile: (414) 412-5869

Sun, 04 Jul 2010 03:10:34 GMT
A question about "kind"?

Quote:

>>> 1. I saw somewhere real(kind = kind(0.0e0)) :: a is suitable for
>>> different computers. But why in C++ the same format can use in
>>> different computers? And in Fotran, why we can't use real(4) and
>>> real(8)?

>>> 2. Are there any advatages of Fortran with real(kind = kind(0.0e0))
>>> and real(kind = kind(0.0d0))  than C++?

>> The key to the answers is that the form real(4) etc. is non-standard
>> and can have different meanings (or even none) on different
>> processors. Thus the other form has the advantage of being standard
>> and portable. Note, however, it can be made less 'wordy' by using
>> named constants for the kinds, as in:

>> integer, parameter ::  sp = kind(0.0e0))
>> integer, parameter ::  dp = kind(0.0d0))
>> real(sp) :: a
>> real(dp) :: b

>> Aso, if ever you run a machine with a very different word length, you
>> can control the actual precisions by changing just one or two
>> statements (see also p. 71 of "Fortran 95/2003 Explained").

>> HTH,
>> Mike Metcalf

>    One minor correction.  The form
>        Real(4)    :: X
> **IS** standard, but it can be non-portable.

>    A Fortran compiler is allowed to have its own unique list of kind
> numbers and the representation method of each.  Although a widely
> observed custom, it is not necessary that a Fortran compiler use the
> kind numbers that correspond to the number of bytes of storage.  E.g.,
> the Siverfrost (formerly Salford) FTN95 compiler uses kind numbers 1, 2,
> and 3 for the Intel 32 bit, 64 bit, and 80 bit reals, respectively.
> Most other compilers would use kind numbers 4, 8, and 10.

>    It is even possible that a Fortran compiler could use different kind
> numbers to distinguish different representation methods that use the
> same amount of storage.  E.g., if a hardware architecture has both a
> native format and an IEEE format for single and double precision reals,
> a Fortran compiler for that hardware could use one kind number for the
> native SP format, a different kind number for the IEEE SP format, and
> third and fourth kind numbers for the native and IEEE DP formats.
> AFAIK, no Fortran compiler actually does this, but it is possible and
> the standard allows it.

>    Best solution:  Develop a module of all kind numbers and other
> processor dependencies and use that module consistently in every program
> and procedure. You can either roll your own or else use Dan Nagle's
> Make_PM program, which is available on his web site.

Since my experience is rather limited, I'd like to know:
(a) which Fortran compilers do not allow real(4)
(b) which Fortran compilers allow real(4) but do not make it correspond
to 32-bit reals.

Sun, 04 Jul 2010 03:25:26 GMT
A question about "kind"?
(snip)

Quote:
>    It is even possible that a Fortran compiler could use different kind
> numbers to distinguish different representation methods that use the
> same amount of storage.  E.g., if a hardware architecture has both a
> native format and an IEEE format for single and double precision reals,
> a Fortran compiler for that hardware could use one kind number for the
> native SP format, a different kind number for the IEEE SP format, and
> third and fourth kind numbers for the native and IEEE DP formats.
> AFAIK, no Fortran compiler actually does this, but it is possible and
> the standard allows it.

VAX has two native double precision formats (possibly implemented in
software on a given implementation).  As far as I know, there aren't
any Fortran 90 compilers for VAX.   Alpha supports the VAX formats
in addition to native IEEE formats.

-- glen

Sun, 04 Jul 2010 04:32:10 GMT
A question about "kind"?
Well, all the below mean the same thing:

Real :: a
Real(kind(0.0e0)) :: a
Real(kind = kind(0.0e0)) :: a

And, all the below mean the same thing:

Double precision :: b
Real(kind(0.0d0)) :: b
Real(kind = kind(0.0d0)) :: b

The type REAL (with no KIND specified) almost certainly always
matches float on your corresponding C or C++ implementation.
The type DOUBLE PRECISION almost certainly matches double
on your corresponding C or C++ implementation.  If that's all
you want, then that's what you can use.

KIND and KIND inquiry functions allow even greater portability
because they allow you to select the precision that's appropriate
to the program, not the precision that's default on the system.
So, if you have a program that needs DOUBLE PRECISION on a
PC class machine and you port it to some mainframe in which
the default REAL *is* IEEE double, that program only needs
single precision on that mainframe.  As you noted though, specific
KIND numbers are *not* portable.

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare

Sun, 04 Jul 2010 06:15:32 GMT
A question about "kind"?

Quote:

> > If one wants to be that pedantic, the correct answer is that whether it
> > is standard or not depends on what compiler you are using.
> I disagree.
...
>     Yes, rule R404 together with constraint C404 require the kind type
> parameter to have a value supported by the processor.  However, this means
> that the use within a program of a non-supported kind type parameter value
> makes the program invalid on that particular processor, but such a program
> is still standard-conforming.

Eh? We apparently don't speak the same language. (But then I've known
that before). A violation of a constraint is one of the most fundamental
ways in which a program can be non-conforming. Note the use of the word
"shall" in the constraint. In 1.7 (of f2003) we have 'In this standard,
"shall" is to be interpreted as a requirement...'. That word is so
fundamental to standards that common parlance in many areas includes the
abomination of using "shall" as a noun, apparently as a synonym for
"requirement".

I was going to quote that constraint (well, actually the corresponding
one for REAL type in order to more directly apply) as incontrovertable
proof of the lackk of standard conformance. I should have known better
than to think that anything would be incontrovertable between us. :-(

--
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain

Sun, 04 Jul 2010 06:53:23 GMT
A question about "kind"?

Quote:

>Since my experience is rather limited, I'd like to know:
>(a) which Fortran compilers do not allow real(4)

NAG f95 Release 5.0 with no -kind option or with -kind=sequential is
one of them. It uses 1 for default real, 2 for double precision.

-- John Harper, School of Mathematics, Statistics and Computer Science,
Victoria University, PO Box 600, Wellington 6140, New Zealand

Sun, 04 Jul 2010 07:43:08 GMT
A question about "kind"?

(snip)

Quote:
> The type REAL (with no KIND specified) almost certainly always
> matches float on your corresponding C or C++ implementation.
> The type DOUBLE PRECISION almost certainly matches double
> on your corresponding C or C++ implementation.  If that's all
> you want, then that's what you can use.

Maybe slightly less certain that Fortran INTEGER is a C int.

Quote:
> KIND and KIND inquiry functions allow even greater portability
> because they allow you to select the precision that's appropriate
> to the program, not the precision that's default on the system.

It is so rare that one knows the required precision, though.
PL/I only allows specification by digits (binary or decimal)
and pretty much everyone puts in the appropriate numbers
for single or double precision on the nearest machine.

Quote:
> So, if you have a program that needs DOUBLE PRECISION on a
> PC class machine and you port it to some mainframe in which
> the default REAL *is* IEEE double, that program only needs
> single precision on that mainframe.  As you noted though, specific
> KIND numbers are *not* portable.

This was true in the CDC 6600 and 7600 days with 60 bit floating
point, and also with the CRAY series with 64 bit single precision,
but those are pretty rare these days.

-- glen

Sun, 04 Jul 2010 08:21:13 GMT
A question about "kind"?

Quote:

> (snip)

>> The type REAL (with no KIND specified) almost certainly always
>> matches float on your corresponding C or C++ implementation.
>> The type DOUBLE PRECISION almost certainly matches double
>> on your corresponding C or C++ implementation.  If that's all
>> you want, then that's what you can use.

> Maybe slightly less certain that Fortran INTEGER is a C int.

Well, there is another option.  As of F2003 you can say:

Integer(C_INT) :: i
Real (C_FLOAT) :: a
Real (C_DOUBLE) :: b
...

Of course you have to USE the ISO_C_BINDING module

Quote:
>> KIND and KIND inquiry functions allow even greater portability
>> because they allow you to select the precision that's appropriate
>> to the program, not the precision that's default on the system.

> It is so rare that one knows the required precision, though.
> PL/I only allows specification by digits (binary or decimal)
> and pretty much everyone puts in the appropriate numbers
> for single or double precision on the nearest machine.

?
I know a lot of people that have a pretty good idea of the precision
required by their programs.  True, they have traditionally just stepped
it up to the next larger available precision on their present target
platform.

Quote:
>> So, if you have a program that needs DOUBLE PRECISION on a
>> PC class machine and you port it to some mainframe in which
>> the default REAL *is* IEEE double, that program only needs
>> single precision on that mainframe.  As you noted though, specific
>> KIND numbers are *not* portable.

> This was true in the CDC 6600 and 7600 days with 60 bit floating
> point, and also with the CRAY series with 64 bit single precision,
> but those are pretty rare these days.

Everything old is new.  The cost of using double instead of single
these days is mostly the extra memory required for the data.  Not
entitrely, but mostly.  It's already tempting to make IEEE double
the default precision and emulating quad (until hardware widely
supports it) as the default for the language's DOUBLE PRECISION.
The only real impediment is that the default INTEGER must be the
same storage size as default REALs, and 64-bit integers are still
not the universal choice.  In any case, it's a mistake to design
languages (or one's own programs) to the current state of environments
or implementations.  Such assumptions can come back to haunt you.

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare

Sun, 04 Jul 2010 08:58:10 GMT
A question about "kind"?

Quote:

>> KIND and KIND inquiry functions allow even greater portability
>> because they allow you to select the precision that's appropriate
>> to the program, not the precision that's default on the system.

>It is so rare that one knows the required precision, though.
>PL/I only allows specification by digits (binary or decimal)
>and pretty much everyone puts in the appropriate numbers
>for single or double precision on the nearest machine.

To avoid unpleasant surprises I try this program whenever we get a new
f95 compiler. Warning: it does not test for different real kinds with
different exponent ranges but the same precision.

INTEGER,PARAMETER :: last = 100, &
rkind(last) = (/(selected_real_kind(i),i=1,last)/), &
ikind(last) = (/(selected_int_kind (i),i=1,last)/)
DO i = 1,last
IF(rkind(i)>=0) &
PRINT *,'selected_real_kind(',i,') = ',rkind(i)
END DO
IF(rkind(last)>=0) PRINT *,'There may be more real kinds'
PRINT *
DO i = 1,last
IF(ikind(i)>=0) &
PRINT *,'selected_int_kind(',i,')  = ',ikind(i)
END DO
IF(ikind(last)>=0) PRINT *,'There may be more integer kinds'
END

-- John Harper, School of Mathematics, Statistics and Computer Science,
Victoria University, PO Box 600, Wellington 6140, New Zealand

Sun, 04 Jul 2010 09:12:53 GMT

 Page 1 of 2 [ 21 post ] Go to page: [1] [2]

Relevant Pages