Author 
Message 
Simulat #1 / 21

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 


Paul van Dels #2 / 21

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 nonstandard?). 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 


Michael Metcal #3 / 21

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 nonstandard 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 


James Van Buskir #4 / 21

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 doubleprecision. The could just as easily have been made single precision or even quad or extandedprecision. 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.5794487871554595D85, & 6.0134700243160014d154/),(/'x'/)); end

Sun, 04 Jul 2010 01:03:04 GMT 


Craig Ded #5 / 21

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 nonstandard 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 nonportable. 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 530080423 Voice: (262) 7835869 Fax: (262) 7835928 Mobile: (414) 4125869

Sun, 04 Jul 2010 01:05:32 GMT 


Richard Mai #6 / 21

A question about "kind"?
Quote:
> > The key to the answers is that the form real(4) etc. is nonstandard > One minor correction. The form > Real(4) :: X > **IS** standard, but it can be nonportable.
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 standardconforming on some compilers, but not on others. It is probably less mindcontorting to just say something like that the code is nonportable. 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 


Craig Ded #7 / 21

A question about "kind"?
Quote:
>> > The key to the answers is that the form real(4) etc. is nonstandard >> One minor correction. The form >> Real(4) :: X >> **IS** standard, but it can be nonportable. > 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 standardconforming on some compilers, but not on others. > It is probably less mindcontorting to just say something like that the > code is nonportable. 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 standardconforming, but not supported. A program is standardconforming 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 nonsupported kind type parameter values is a form described in the standard and it has an interpretation according to the standard. A standardconforming Fortran compiler is required to report the use of nonsupported 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 nonsupported kind type parameter value makes the program invalid on that particular processor, but such a program is still standardconforming.  Craig Dedo 17130 W. Burleigh Place P. O. Box 423 Brookfield, WI 530080423 Voice: (262) 7835869 Fax: (262) 7835928 Mobile: (414) 4125869

Sun, 04 Jul 2010 03:10:34 GMT 


Gib Bogl #8 / 21

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 nonstandard >> 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 nonportable. > 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 32bit reals.

Sun, 04 Jul 2010 03:25:26 GMT 


glen herrmannsfeld #9 / 21

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 


James Gile #10 / 21

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 


Richard Mai #11 / 21

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 nonsupported kind type parameter value > makes the program invalid on that particular processor, but such a program > is still standardconforming.
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 nonconforming. 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 


John Harp #12 / 21

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 


glen herrmannsfeld #13 / 21

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 


James Gile #14 / 21

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 64bit 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 


John Harp #15 / 21

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] 
1. beginners "let"/"random" question
2. Creating special kind of "application"?
3. Better ways of expressing "KIND"
4. string.join(["Tk 4.2p2", "Python 1.4", "Win32", "free"], "for")
5. BEGIN{want[]={"s1o", "s2o", "s2q", "s3q"}
6. Parsing ""D""?
7. "Fifth", "Forth", zai nar?
8. Ruby "finalize", "__del__"
9. ANNOUNCE: new "plus" and "dash"patches available for Tcl7.5a2/Tk4.1a2
10. Looking for "stdin", "stdout"
11. MicroWorlds Pro "QUESTION Set Size" question
12. Hi, this code: text0 = "One $BLAH Three" text1 = "One @BLAH Three" text0.sub!("$BLAH", "Two") text1.sub!("@BLAH", "Two") print text0,"\n" print text1,"\n" produces thiHi, this code: text0 = "One $BLAH Three" text1 = "One @BLAH Three" text0.sub!("$BLAH", "T


