Prev: Clarify An Old Question: define a user data containing array with dimensions decided in running time
Next: Clarify An Old Question: define a user data containing array with ?dimensions decided in running time
From: Richard Maine on 24 May 2010 12:58 glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote: > Richard Maine <nospam(a)see.signature> wrote: > (snip) > > > Using selected_int_kind for Hollerith is .... um... "pointless" seems > > too mild a word. I'd think it closer to some kind of candidate for the > > most inappropriate mixture of styles that one can devise. Expecting to > > do so portably is beyond the pale. > > I would like to see a Fortran 2003 compiler on a 36 bit machine, > though. Not that I would use Hollerith constants on one. Recall that Hollerith was dropped from the main body of the standard as of f77. As of f90, it isn't even mentioned in an Appendix. There went any guarantees of portability in terms of even having both selected_int_kind and Hollerith in the same compiler at all, independent of any question about what selected_int_kind will return. That puts you back to speculating how likely various implementations are to do things. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: Uno on 24 May 2010 18:59 dpb wrote: > dpb wrote: > ... > >> I don't believe the above is guaranteed to work by Standard ... > > Actually, I'm sure it's not... :) Then I would commend JVB's version of this stuff to Tobias. I had to print out the values to understand what makes it work, but it is completely portable. -- Uno
From: Uno on 24 May 2010 23:38 On 5/23/2010 3:12 PM, Richard Maine wrote: (snip) > > For f90/f95/f2003, it will suffice in practice to do something like > selected_int_kind(9). That's what I use. That doesn't strictly guarantee > a 4-byte integer... but you won't find any compilers where that's not > what you get. Tobias had coded it without me noticing: [judy1.f90 uses tobias1.f90 as a template; I make sure I have an executable before I gut it.] Dir for this script: E:\gcc_eq32\ E:\gcc_eq32>gfortran -Wall -Wextra judy1.f90 -o out.exe E:\gcc_eq32>out 4 8 10 3.1415927 3.1415926535897931 3.1415926535897932385 E:\gcc_eq32>type tobias1.f90 implicit none integer, parameter :: sp = selected_real_kind(1,3) integer, parameter :: dp = selected_real_kind(15,300) integer, parameter :: qp = & max(kind(0.0d0), selected_real_kind(precision(0.0d0)+1)) real (kind=sp) w real (kind=dp) y real (kind=qp) z w = 4.0_sp*atan(1.0_sp) y = 4.0_dp*atan(1.0_dp) z = 4.0_qp*atan(1.0_qp) print *, sp,dp,qp print *, w,y,z endprogram ! gfortran -Wall -Wextra tobias1.f90 -o out.exe E:\gcc_eq32> -- Uno
From: Ron Shepard on 25 May 2010 01:02 In article <htds7s$cm9$1(a)news.eternal-september.org>, dpb <none(a)non.net> wrote: > >>> precsion, I use: > >>> integer, parameter :: qp = & > >>> max(kind(0.0d0), selected_real_kind(precision(0.0d0)+1)) > > > > Heavens, NO!!! > ... > > Ooops, sorry, I forgot the MAX() call...that does, indeed assume the > ordering; I was focused on thinking you were looking at the addition > operation. It does work "correctly" in the case that kind(0.0d0) is the largest precision supported. Where it might not work is when there is a higher precision that happens to have a smaller kind value. $.02 -Ron Shepard
From: Uno on 25 May 2010 02:25
On 5/24/2010 10:02 PM, Ron Shepard wrote: > In article<htds7s$cm9$1(a)news.eternal-september.org>, > dpb<none(a)non.net> wrote: > >>>>> precsion, I use: >>>>> integer, parameter :: qp =& >>>>> max(kind(0.0d0), selected_real_kind(precision(0.0d0)+1)) >>> >>> Heavens, NO!!! >> ... >> >> Ooops, sorry, I forgot the MAX() call...that does, indeed assume the >> ordering; I was focused on thinking you were looking at the addition >> operation. > > It does work "correctly" in the case that kind(0.0d0) is the largest > precision supported. Where it might not work is when there is a higher > precision that happens to have a smaller kind value. right -- |