busting sp datatypes

LR wrote:
(snip)

> Just out of curiosity, could you please show me what this would look
> like if x was character*7 instead of integer?

Here is a version that actually works with g95 0.91,
unlike the one I posted earlier.

integer function compare(i1,i2)
compare=0
if(i1>i2) compare=1
if(i1<i2) compare=-1
return
end

use ISO_C_BINDING
external :: compare
interface
subroutine qsort(a,i,n,f) bind(c)
integer,value:: i,n
integer a(n)
external f
end subroutine qsort
end interface

integer x(10)
read(*,*) x
call qsort(x,10,4,compare)
write(*,*) x
end

CHARACTER is a little more complicated, as Fortran
passes the length information and C doesn't.

-- glen

glen herrmannsfeldt wrote:
> LR wrote:
> (snip)
>
>> Just out of curiosity, could you please show me what this would look
>> like if x was character*7 instead of integer?
>
> Here is a version that actually works with g95 0.91,
> unlike the one I posted earlier.
>
> integer function compare(i1,i2)
> compare=0
> if(i1>i2) compare=1
> if(i1<i2) compare=-1
> return
> end
>
> use ISO_C_BINDING
> external :: compare
> interface
> subroutine qsort(a,i,n,f) bind(c)
> integer,value:: i,n
> integer a(n)
> external f
> end subroutine qsort
> end interface
>
> integer x(10)
> read(*,*) x
> call qsort(x,10,4,compare)
> write(*,*) x
> end
>
> CHARACTER is a little more complicated, as Fortran
> passes the length information and C doesn't.


IIRC equivalence is being depreciated, but would it be of help here to
equivalence
character*7 x(10)
to something like
integer*1 x(7)(10)
I haven't had to worry about the order of those kinds of dimensions in
quite some time, so sorry if I got those wrong. Also, I'm not sure that
integer*1 is legal or even possible.

Then perhaps some version of compare that looked like:
integer function compare(i1,i2)
integer*1 i1(7),i2(7), ic1,ic2
character*1 c1,c2
equivalence (ic1,c1), (ic2,c2)
compare=0
do i = 1, 7
ic1 = i1(i)
ic2 = i2(i)
if(c1>c2) then
compare=1
return
endif
if(i1<i2) then
compare=-1
return
endif
end do
return
end

But its been a very long time since I wrote Fortran, so there's probably
a way nicer way to do it. But will this do it in principle? What if
equivalence really is depreciated?

LR

In article <eyv2argkr81d$.dlg@example.invalid>,
Ron Ford <ron@example.invalid> writes:
> On Thu, 28 Aug 2008 03:15:32 +0000 (UTC), Steven G. Kargl posted:
>
>> In article <otfdd3cv5rxp.dlg@example.invalid>,
>> Ron Ford <ron@example.invalid> writes:
>>> ! inner loop rolls die till all values attained
>>> do
>>> call random_number(harvest)
>>> b = ceiling(harvest*real(sides))
>>
>> b = min(max(1,ceiling(harvest*sides)),sides)

(large program removed)


>>> F:\gfortran\source>sort
>>> n= 8
>>> clock= 108897905
>>> seed= 108897905 108897942 108897979 108898016 108898053
>>> 108898090
>>> 108898127 108898164
>>> 1 0.42305011
>>> 2 8.57861638E-02
>>> 3 0.40694624
>>> At line 158 of file freeformat50.f95
>>> Fortran runtime error: Array reference out of bounds for array 'a', lower
>>> bound of dimension 1 exceeded (0 < 1)
>>
>> Read the error message.
>
> The error message leads me to think that numbers get so large that A(b) is
> A(0). b doesn't get bigger than 8. A(b) doesn't exceed one hundred.

Admittedly, the word 'exceeded' may be misleading, but I've given you
all the info you need. But, I'll spell it out for you.

b = min(max(1,ceiling(harvest*sides)),sides)

The above statement ensures that b is within the range [1:sides].
Why is this important ...

>> Then read the description of random_number().
>
> I thought I worked these kinks out earlier.

because when you read the description of random_number(), you'll
find that your variable harvest is in the range [0,1). This includes
the value 0.e0. New re-read the error message. Your index is b = 0,
and it 'exceeds' the lower bound of 1.

--
Steve
http://troutmask.apl.washington.edu/~kargl/

LR wrote:
> (snip)

> Just out of curiosity, could you please show me what this would look
> like if x was character*7 instead of integer?

Here is a mixed Fortran/C version. I believe that bugs in
g95 0.91 are stopping the all Fortran version from compiling.
(Yes, I should use a newer version.)

use ISO_C_BINDING
interface
subroutine qsort(a,i,n,f) bind(c)
integer,value :: i,n
character*7 a(n)
external f
end subroutine qsort
integer function compare(a,b) bind(c,name="compare")
character*7 a,b
end function compare
end interface

character*7 x(10)
read(*,*) x
! without c_sizeof(), the 7 in the qsort call assumes
! no padding in the array. It works with g95, but I don't
! know if other compilers might add padding.
!
call qsort(x,10,7,compare)
! write(*,*) x
write(*,3) x
3 format(' ''',A7,'''')
end

/* called by qsort from Fortran */
#include <string.h>
int compare(char *a, char *b) {
return strncmp(a,b,7);
}

On Thu, 28 Aug 2008 18:53:17 +0000 (UTC), Steven G. Kargl posted:

> In article <eyv2argkr81d$.dlg@example.invalid>,
> Ron Ford <ron@example.invalid> writes:

> Admittedly, the word 'exceeded' may be misleading, but I've given you
> all the info you need. But, I'll spell it out for you.
>
> b = min(max(1,ceiling(harvest*sides)),sides)
>
> The above statement ensures that b is within the range [1:sides].
> Why is this important ...
>
>>> Then read the description of random_number().
>>
>> I thought I worked these kinks out earlier.
>
> because when you read the description of random_number(), you'll
> find that your variable harvest is in the range [0,1). This includes
> the value 0.e0. New re-read the error message. Your index is b = 0,
> and it 'exceeds' the lower bound of 1.

Ah, yes, the interval is closed on the left. I wrote a little prog to see
how often this happens:


implicit none
integer, parameter :: i13 = selected_int_kind(13)
integer(i13), parameter:: trials = 30000000
integer(i13):: i


real:: harvest
CALL init_random_seed

do i = 1, trials
call random_number(harvest)
if (harvest ==0.0) then
print *, i, harvest
end if
end do


contains
SUBROUTINE init_random_seed()
INTEGER :: i, n, clock
INTEGER, DIMENSION(, ALLOCATABLE :: seed

CALL RANDOM_SEED(size = n)
print *, "n=", n
ALLOCATE(seed(n))

CALL SYSTEM_CLOCK(COUNT=clock)
print *, "clock=", clock

seed = clock + 37 * (/ (i - 1, i = 1, n) /)
CALL RANDOM_SEED(PUT = seed)
print *, "seed= ", seed

DEALLOCATE(seed)
END SUBROUTINE
end program

n= 1
clock= 24470861
seed= 24470861
2478608 0.00000
3010798 0.00000
17945413 0.00000
19503539 0.00000

Press RETURN to close window . . .

0. e0 would appear to be one out of every eight million draws.

The work-around with the minmax does fine. Thanks for your attention,
Steve.
--
What men value in this world is not rights but privileges. 7
H. L. Mencken

LR <lruss@superlink.net> wrote:

> IIRC equivalence is being depreciated,

Not formally in the standard. In fact the concept of deprecation was
dropped from the f90 draft before it ever got formally into the
standard. Plenty of individuals (myself included) personally consider
equivalence to be deprecated, but that needs to be qualified as a
position of the individuals in question instead of just is "is being
deprecated".

> but would it be of help here to equivalence
> character*7 x(10)
> to something like
> integer*1 x(7)(10)
> I haven't had to worry about the order of those kinds of dimensions in
> quite some time, so sorry if I got those wrong. Also, I'm not sure that
> integer*1 is legal or even possible.

Well now we don't need to get into deprecation to see "issues" with
that. Equivalencing character with non-character data has never been
standard in the first place (which is quite a bit more severe then being
deprecated). Nor has the integer*1 syntax. Even among compilers that
accepted the nonstandard integer* syntax, some did not allow *1.

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

glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

> character*7 x(10)
....
> ! without c_sizeof(), the 7 in the qsort call assumes
> ! no padding in the array. It works with g95, but I don't
> ! know if other compilers might add padding.

If they claim to conform to the standard, they better not. Derived types
are a different matter, but character is pretty much "tied down" in such
matters. Not worth digging out the citations.

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

On Tue, 26 Aug 2008 12:25:15 -0700 (PDT), pintar.andy@gmail.com posted:

> On Aug 25, 6:10*pm, Ron Ford <r...@example.invalid> wrote:
>> It's been a while since I've turned a program from sp to dp, and I wanted
>> to check my premises. *First, does this
>> INTEGER, PARAMETER :: DP = KIND(1.0D0) * *! define DP
>> give dp for all of the following:
>> integer(kind=dp), parameter:: trials = 300000
>> integer (kind=dp), dimension(trials)::F
>> real (kind=dp):: harvest, tot, t1, t2, diff, t3, t4
>
> I'm not sure exactly why you're concerned about single vs. double
> precision integers. However, there's a nice compiler option which I
> often use which forces reals to be double. Using gfortran, the
> options are:
> -fdefault-double-8 -fdefault-integer-8 -fdefault-real-8
> I then just declare reals and then can switch between single and
> double at compile-time.

Andy,

I'm only somewhat familiar with gfortran's scheme for kinds. Let's see if
I understand you:

1) -fdefault-integer-8 gives the maximum width for a default integer.

2) -fdefault-real-8 gives a dp real

3) -fdefault-double-8 This looks like C to me. ??

A beautiful day in the Rockies, and I've been avoiding the day's work.
--
War will never cease until babies begin to come into the world with larger
cerebrums and smaller adrenal glands. 2
H. L. Mencken

On Thu, 28 Aug 2008 14:24:38 -0400, LR <lruss@superlink.net>
wrote in <48b6ed30$0$31956$cc2e38e6@news.uslec.net>:

> IIRC equivalence is being depreciated

"deprecated", please. It's not going down in value.

deprecate
vt: ... to express disapproval of; ...
--Chambers Dictionary

--
Ivan Reid, School of Engineering & Design, _____________ CMS Collaboration,
Brunel University. Ivan.Reid@[brunel.ac.uk|cern.ch] Room 40-1-B12, CERN
KotPT -- "for stupidity above and beyond the call of duty".

Dr Ivan D. Reid <Ivan.Reid@brunel.ac.uk> wrote:

> On Thu, 28 Aug 2008 14:24:38 -0400, LR <lruss@superlink.net>
> wrote in <48b6ed30$0$31956$cc2e38e6@news.uslec.net>:
>
> > IIRC equivalence is being depreciated
>
> "deprecated", please. It's not going down in value.

Hmm. Well I suppose one might argue for either point. :-)

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