From: Richard Maine on
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
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
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
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
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
--