f



NEWBIE QUESTION: "Warning: Extension: REAL array index at (1)" - please help

Hi,

Really really simple question:

------
PROGRAM ex1
   type element_def
      real(kind =8) :: element_angle
   end type element_def
   type(element_def), dimension(:), allocatable :: element

   INTEGER n

   n=10
   allocate(element(n))

   element%element_angle = 0.0
   do e=1,n
      print*,'e=',e,': ', (element(e)%element_angle)*180/pi
      element(e)%element_angle = 999.0
   end do
   do e=1,n
      print*,'e=',e,': ', (element(e)%element_angle)*180/pi
   end do


END PROGRAM ex1
------


Compilation error:

----
gfortran test.f90
  In file test.f90:15

      print*,'e=',e,': ', (element(e)%element_angle)*180/pi
                                  1
Warning: Extension: REAL array index at (1)
  In file test.f90:16

      element(e)%element_angle = 999.0
             1
Warning: Extension: REAL array index at (1)
  In file test.f90:19

      print*,'e=',e,': ', (element(e)%element_angle)*180/pi
                                  1
Warning: Extension: REAL array index at (1)
----


Program output:

  e=   1.000000     :    0.00000000000000
  e=   2.000000     :    0.00000000000000
  e=   3.000000     :    0.00000000000000
  e=   4.000000     :    0.00000000000000
  e=   5.000000     :    0.00000000000000
  e=   6.000000     :    0.00000000000000
  e=   7.000000     :    0.00000000000000
  e=   8.000000     :    0.00000000000000
  e=   9.000000     :    0.00000000000000
  e=   10.00000     :    0.00000000000000
  e=   1.000000     :   -89922.3703975008
  e=   2.000000     :   -89922.3703975008
  e=   3.000000     :   -89922.3703975008
  e=   4.000000     :   -89922.3703975008
  e=   5.000000     :   -89922.3703975008
  e=   6.000000     :   -89922.3703975008
  e=   7.000000     :   -89922.3703975008
  e=   8.000000     :   -89922.3703975008
  e=   9.000000     :   -89922.3703975008
  e=   10.00000     :   -89922.3703975008


I would have expected that e=1....10 would be 999.0.

Please help me understand this, preferably tonight if possible as I'm 
sitting and trying to make this piece of code work - and it should be so 
simple that I think it'll be easy to tell what I'm doing wrong?

TIA.


Best regards,
Martin
0
megafedt (49)
11/7/2007 8:00:21 PM
comp.lang.fortran 11941 articles. 2 followers. Post Follow

17 Replies
908 Views

Similar Articles

[PageSpeed] 50

"Martin J�rgensen" <megafedt@hotmail.com> wrote in message 
news:4732195f$0$90273$14726298@news.sunsite.dk...
>
>      print*,'e=',e,': ', (element(e)%element_angle)*180/pi
>                                  1
Yes. Fortran has implicit typing rules: variables whose first letter is in 
the range i to m are integer, all others, here 'e', are real. The use of a 
real do-construct index is not permitted by the standard, it is thus an 
extension.

The lesson learnt is to add the statement 'implicit none' at the beginning 
of each program unit, and this will then not allow you to use implicit 
typing. In your example, 'integer :: e' is required. (See also Section 7.2 
of "Fortran 95/2003 Explained" for lots of gory details.)

HTH

Mike Metcalf 


0
11/7/2007 8:10:16 PM
"Michael Metcalf" <michaelmetcalf@compuserve.com> wrote in message 
news:IYoYi.2870$bm.1871@trndny08...
>
> "Martin J�rgensen" <megafedt@hotmail.com> wrote in message 
> news:4732195f$0$90273$14726298@news.sunsite.dk...
>>
>>      print*,'e=',e,': ', (element(e)%element_angle)*180/pi
>>                                  1
> range i to m are integer,

Sorry, i to n.

M. 


0
11/7/2007 8:11:21 PM
Martin J�rgensen wrote:
....

> PROGRAM ex1
>   type element_def
>      real(kind =8) :: element_angle
>   end type element_def
>   type(element_def), dimension(:), allocatable :: element
> 
>   INTEGER n
> 
>   n=10
>   allocate(element(n))
> 
>   element%element_angle = 0.0
>   do e=1,n
>      print*,'e=',e,': ', (element(e)%element_angle)*180/pi
>      element(e)%element_angle = 999.0
>   end do
....

Michael M answered the compiler question.

I'd add it would be wise to get into the habit of using "implicit none" 
in all your programs -- then you would have had a message telling you 
"e" wasn't declared and would have explicitly declared it as you intended.

Also, note above that your print statement is before the statement which 
assigns a value to the "e-th" array alement--probably not what you intended.

--
0
none1568 (7453)
11/7/2007 8:24:03 PM
In article <4732195f$0$90273$14726298@news.sunsite.dk>,
	Martin J�rgensen <megafedt@hotmail.com> writes:

> PROGRAM ex1

     integer, parameter :: dp = kind(1.d0)
>    type element_def
>       real(kind =8) :: element_angle

        real(kind=dp) :: element_angle

>    end type element_def
>    type(element_def), dimension(:), allocatable :: element
> 
>    INTEGER n

     integer e
     real(kind=8) pi

     pi = 2._dp * asin(1._dp)

>    n=10
>    allocate(element(n))
> 
>    element%element_angle = 0.0

     element%element_angle = 0.0_dp


>    do e=1,n
>       print*,'e=',e,': ', (element(e)%element_angle)*180/pi
>       element(e)%element_angle = 999.0

        element(e)%element_angle = 999.0_dp


>    end do
>    do e=1,n
>       print*,'e=',e,': ', (element(e)%element_angle)*180/pi
>    end do
> 
> 
> END PROGRAM ex1
> ------
> 
> 
> Compilation error:
> 
> ----
> gfortran test.f90

gfortran -Wall test.f90

-- 
Steve
http://troutmask.apl.washington.edu/~kargl/
0
kargl (773)
11/7/2007 8:26:55 PM
Martin J�rgensen <megafedt@hotmail.com> wrote:

> PROGRAM ex1
>    type element_def
>       real(kind =8) :: element_angle
>    end type element_def
>    type(element_def), dimension(:), allocatable :: element
> 
>    INTEGER n
> 
>    n=10
>    allocate(element(n))
> 
>    element%element_angle = 0.0
>    do e=1,n
>       print*,'e=',e,': ', (element(e)%element_angle)*180/pi
>       element(e)%element_angle = 999.0
>    end do
>    do e=1,n
>       print*,'e=',e,': ', (element(e)%element_angle)*180/pi
>    end do
>  
> END PROGRAM ex1

> Compilation error:
....
> Warning: Extension: REAL array index at (1)

First note that this is not a compilation error. It is a warning rather
than an error. If it were an error, the compiler would not have made a
runnable executable. However, the problem should still be fixed.

The problem is that e is implicitly of real type because you never gave
it a type. I strongly recommend explicitly typing everything and using
implicit none to enforce that. You should declare e as integer. As the
message implies, it is nonstandard to use a real varoable as an array
index, but the compiler accepts it anyway. It is also obsolescent (or
maybe a deleted feature; I'd have to check to be sure) to use a real
variable as a loop index.

However, that doesn't directly relate to your problem with the output.

> Program output:
> 
>   e=   1.000000     :    0.00000000000000
>   e=   2.000000     :    0.00000000000000
>   e=   3.000000     :    0.00000000000000
>   e=   4.000000     :    0.00000000000000
>   e=   5.000000     :    0.00000000000000
>   e=   6.000000     :    0.00000000000000
>   e=   7.000000     :    0.00000000000000
>   e=   8.000000     :    0.00000000000000
>   e=   9.000000     :    0.00000000000000
>   e=   10.00000     :    0.00000000000000
>   e=   1.000000     :   -89922.3703975008
>   e=   2.000000     :   -89922.3703975008
>   e=   3.000000     :   -89922.3703975008
>   e=   4.000000     :   -89922.3703975008
>   e=   5.000000     :   -89922.3703975008
>   e=   6.000000     :   -89922.3703975008
>   e=   7.000000     :   -89922.3703975008
>   e=   8.000000     :   -89922.3703975008
>   e=   9.000000     :   -89922.3703975008
>   e=   10.00000     :   -89922.3703975008
> 
> 
> I would have expected that e=1....10 would be 999.0.

The first 10 lines are from before you set the values to 999. You print
the output and *THEN* set the value to 999. Order matters.

The last 10 lines are after you have set the value to 999, but I don't
know why you would expect the printout to show 999. You aren't printing
out element(e)%element_angle. You are printing that times 180/pi, which
would be something more like 3139..... that is assuming that you intend
pi to be approximately 3.14159 or so. However, you never defined pi, so
it is presumably some random value from whatever was in memory. Just
because you named it pi, that doesn't mean it automatically has the
value you intend.

-- 
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain
0
nospam47 (9747)
11/7/2007 8:38:06 PM
Martin J�rgensen wrote:
> Hi,
> 
> Really really simple question:
> 
> ------
> PROGRAM ex1
>   type element_def
>      real(kind =8) :: element_angle
>   end type element_def
>   type(element_def), dimension(:), allocatable :: element
> 
>   INTEGER n
> 
>   n=10
>   allocate(element(n))
> 
>   element%element_angle = 0.0
>   do e=1,n
>      print*,'e=',e,': ', (element(e)%element_angle)*180/pi
>      element(e)%element_angle = 999.0
>   end do
>   do e=1,n
>      print*,'e=',e,': ', (element(e)%element_angle)*180/pi
>   end do
> 
> 
> END PROGRAM ex1
> ------
> 
> 
> Compilation error:
> 
> ----
> gfortran test.f90
>  In file test.f90:15
> 
>      print*,'e=',e,': ', (element(e)%element_angle)*180/pi
>                                  1
> Warning: Extension: REAL array index at (1)
>  In file test.f90:16
> 
>      element(e)%element_angle = 999.0
>             1
> Warning: Extension: REAL array index at (1)
>  In file test.f90:19
> 
>      print*,'e=',e,': ', (element(e)%element_angle)*180/pi
>                                  1
> Warning: Extension: REAL array index at (1)
> ----
> 
> 
> Program output:
> 
>  e=   1.000000     :    0.00000000000000
>  e=   2.000000     :    0.00000000000000
>  e=   3.000000     :    0.00000000000000
>  e=   4.000000     :    0.00000000000000
>  e=   5.000000     :    0.00000000000000
>  e=   6.000000     :    0.00000000000000
>  e=   7.000000     :    0.00000000000000
>  e=   8.000000     :    0.00000000000000
>  e=   9.000000     :    0.00000000000000
>  e=   10.00000     :    0.00000000000000
>  e=   1.000000     :   -89922.3703975008
>  e=   2.000000     :   -89922.3703975008
>  e=   3.000000     :   -89922.3703975008
>  e=   4.000000     :   -89922.3703975008
>  e=   5.000000     :   -89922.3703975008
>  e=   6.000000     :   -89922.3703975008
>  e=   7.000000     :   -89922.3703975008
>  e=   8.000000     :   -89922.3703975008
>  e=   9.000000     :   -89922.3703975008
>  e=   10.00000     :   -89922.3703975008
> 
> 
> I would have expected that e=1....10 would be 999.0.
> 
> Please help me understand this, preferably tonight if possible as I'm 
> sitting and trying to make this piece of code work - and it should be so 
> simple that I think it'll be easy to tell what I'm doing wrong?
> 
> TIA.
> 
> 
> Best regards,
> Martin
To answer your real question, element(e)%element_angle is almost
for sure 999.0.  But, what you are printing is
element(e)%element_angle*180/pi
and you haven't given pi a value.  Try pi = 3.14
and things should work.

All of the other suggestions were good ones, but they overlooked
the undefined variable.

Dick Hendrickson
0
11/7/2007 8:42:44 PM
Richard Maine <nospam@see.signature> wrote:

> The last 10 lines are after you have set the value to 999, but I don't
> know why you would expect the printout to show 999. You aren't printing
> out element(e)%element_angle. You are printing that times 180/pi, which
> would be something more like 3139..... 

Um. Make that more like 57000. I had a temporary disconnect between
brain and keyboard.

-- 
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain
0
nospam47 (9747)
11/7/2007 8:45:35 PM
Richard Maine wrote:

(snip)

>>   do e=1,n
>>      print*,'e=',e,': ', (element(e)%element_angle)*180/pi
>>      element(e)%element_angle = 999.0
>>   end do

(snip)

>>Warning: Extension: REAL array index at (1)

> First note that this is not a compilation error. It is a warning rather
> than an error. If it were an error, the compiler would not have made a
> runnable executable. However, the problem should still be fixed.

> The problem is that e is implicitly of real type because you never gave
> it a type. I strongly recommend explicitly typing everything and using
> implicit none to enforce that. You should declare e as integer. As the
> message implies, it is nonstandard to use a real varoable as an array
> index, but the compiler accepts it anyway. It is also obsolescent (or
> maybe a deleted feature; I'd have to check to be sure) to use a real
> variable as a loop index.

REAL variables as subscripts are an extension in many systems.

While 99.9% of the time a DO variable should not be real, it doesn't
seem so bad to have it in the language for the times it is useful.
It seems to be a deleted feature.

> However, that doesn't directly relate to your problem with the output.
(snip)
 > You are printing that times 180/pi, which
> would be something more like 3139..... that is assuming that you intend
> pi to be approximately 3.14159 or so. However, you never defined pi, so
> it is presumably some random value from whatever was in memory. Just
> because you named it pi, that doesn't mean it automatically has the
> value you intend.

Other languages do have a defined pi.

Java has Math.PI (a static final variable in the class Math).

I even knew a BASIC system with P1 initialized to pi.

-- glen

0
gah (12851)
11/8/2007 2:22:39 AM
dpb wrote:
> Martin J�rgensen wrote:
> ...
> 
>> PROGRAM ex1
>>   type element_def
>>      real(kind =8) :: element_angle
>>   end type element_def
>>   type(element_def), dimension(:), allocatable :: element
>>
>>   INTEGER n
>>
>>   n=10
>>   allocate(element(n))
>>
>>   element%element_angle = 0.0
>>   do e=1,n
>>      print*,'e=',e,': ', (element(e)%element_angle)*180/pi
>>      element(e)%element_angle = 999.0
>>   end do
> ...
> 
> Michael M answered the compiler question.

Thanks for that.

> I'd add it would be wise to get into the habit of using "implicit none" 
> in all your programs -- then you would have had a message telling you 
> "e" wasn't declared and would have explicitly declared it as you intended.

Aha.... Thanks. I also have that somewhere else, but perhaps I was 
stupid enough to remove it once I got errors/warnings I didn't wanted to 
look at... I'll keep it in the future.

> Also, note above that your print statement is before the statement which 
> assigns a value to the "e-th" array alement--probably not what you 
> intended.

Actually I wanted to see both the zeros and the 999.0. But ofcourse I 
shouldn't multiply with 180/pi - that is because I'm using the program 
piece in another program, where it's an angle and then I forgot to 
modify the test-example, which I posted.


Thanks again,

Martin
0
megafedt (49)
11/8/2007 3:34:24 AM
Richard Maine wrote:
> Martin J�rgensen <megafedt@hotmail.com> wrote:
> 
>> PROGRAM ex1
>>    type element_def
>>       real(kind =8) :: element_angle
>>    end type element_def
>>    type(element_def), dimension(:), allocatable :: element
>>
>>    INTEGER n
>>
>>    n=10
>>    allocate(element(n))
>>
>>    element%element_angle = 0.0
>>    do e=1,n
>>       print*,'e=',e,': ', (element(e)%element_angle)*180/pi
>>       element(e)%element_angle = 999.0
>>    end do
>>    do e=1,n
>>       print*,'e=',e,': ', (element(e)%element_angle)*180/pi
>>    end do
>>  
>> END PROGRAM ex1
> 
>> Compilation error:
> ...
>> Warning: Extension: REAL array index at (1)
> 
> First note that this is not a compilation error. It is a warning rather
> than an error. If it were an error, the compiler would not have made a
> runnable executable. However, the problem should still be fixed.
> 
> The problem is that e is implicitly of real type because you never gave
> it a type. I strongly recommend explicitly typing everything and using
> implicit none to enforce that. You should declare e as integer. As the
> message implies, it is nonstandard to use a real varoable as an array
> index, but the compiler accepts it anyway. It is also obsolescent (or
> maybe a deleted feature; I'd have to check to be sure) to use a real
> variable as a loop index.
> 
> However, that doesn't directly relate to your problem with the output.
> 
>> Program output:
>>
>>   e=   1.000000     :    0.00000000000000
>>   e=   2.000000     :    0.00000000000000
>>   e=   3.000000     :    0.00000000000000
>>   e=   4.000000     :    0.00000000000000
>>   e=   5.000000     :    0.00000000000000
>>   e=   6.000000     :    0.00000000000000
>>   e=   7.000000     :    0.00000000000000
>>   e=   8.000000     :    0.00000000000000
>>   e=   9.000000     :    0.00000000000000
>>   e=   10.00000     :    0.00000000000000
>>   e=   1.000000     :   -89922.3703975008
>>   e=   2.000000     :   -89922.3703975008
>>   e=   3.000000     :   -89922.3703975008
>>   e=   4.000000     :   -89922.3703975008
>>   e=   5.000000     :   -89922.3703975008
>>   e=   6.000000     :   -89922.3703975008
>>   e=   7.000000     :   -89922.3703975008
>>   e=   8.000000     :   -89922.3703975008
>>   e=   9.000000     :   -89922.3703975008
>>   e=   10.00000     :   -89922.3703975008
>>
>>
>> I would have expected that e=1....10 would be 999.0.
> 
> The first 10 lines are from before you set the values to 999. You print
> the output and *THEN* set the value to 999. Order matters.
> 
> The last 10 lines are after you have set the value to 999, but I don't
> know why you would expect the printout to show 999. You aren't printing
> out element(e)%element_angle. You are printing that times 180/pi, which
> would be something more like 3139..... that is assuming that you intend
> pi to be approximately 3.14159 or so. However, you never defined pi, so
> it is presumably some random value from whatever was in memory. Just
> because you named it pi, that doesn't mean it automatically has the
> value you intend.

I forgot to remove 180/pi, but I get it. Thanks. Must have implicit none 
and be careful with those random numbers...

Martin
0
megafedt (49)
11/8/2007 3:35:46 AM
glen herrmannsfeldt wrote:
> Richard Maine wrote:
> 
> (snip)
> 
>>>   do e=1,n
>>>      print*,'e=',e,': ', (element(e)%element_angle)*180/pi
>>>      element(e)%element_angle = 999.0
>>>   end do
> 
> (snip)
> 
>>> Warning: Extension: REAL array index at (1)
> 
>> First note that this is not a compilation error. It is a warning rather
>> than an error. If it were an error, the compiler would not have made a
>> runnable executable. However, the problem should still be fixed.
> 
>> The problem is that e is implicitly of real type because you never gave
>> it a type. I strongly recommend explicitly typing everything and using
>> implicit none to enforce that. You should declare e as integer. As the
>> message implies, it is nonstandard to use a real varoable as an array
>> index, but the compiler accepts it anyway. It is also obsolescent (or
>> maybe a deleted feature; I'd have to check to be sure) to use a real
>> variable as a loop index.
> 
> REAL variables as subscripts are an extension in many systems.
> 
> While 99.9% of the time a DO variable should not be real, it doesn't
> seem so bad to have it in the language for the times it is useful.
> It seems to be a deleted feature.

What does it do? Convert the real number to integer and throw away the 
digits? Or does it round-off to index something?

>> However, that doesn't directly relate to your problem with the output.
> (snip)
>  > You are printing that times 180/pi, which
>> would be something more like 3139..... that is assuming that you intend
>> pi to be approximately 3.14159 or so. However, you never defined pi, so
>> it is presumably some random value from whatever was in memory. Just
>> because you named it pi, that doesn't mean it automatically has the
>> value you intend.

Yep, ok.
0
megafedt (49)
11/8/2007 3:37:12 AM
Martin J�rgensen wrote:
> glen herrmannsfeldt wrote:
>> Richard Maine wrote:
>>
>> (snip)
>>
>>>>   do e=1,n
>>>>      print*,'e=',e,': ', (element(e)%element_angle)*180/pi
>>>>      element(e)%element_angle = 999.0
>>>>   end do
>>
>> (snip)
>>
>>>> Warning: Extension: REAL array index at (1)
>>
>>> First note that this is not a compilation error. It is a warning rather
>>> than an error. If it were an error, the compiler would not have made a
>>> runnable executable. However, the problem should still be fixed.
>>
>>> The problem is that e is implicitly of real type because you never gave
>>> it a type. I strongly recommend explicitly typing everything and using
>>> implicit none to enforce that. You should declare e as integer. As the
>>> message implies, it is nonstandard to use a real varoable as an array
>>> index, but the compiler accepts it anyway. It is also obsolescent (or
>>> maybe a deleted feature; I'd have to check to be sure) to use a real
>>> variable as a loop index.
>>
>> REAL variables as subscripts are an extension in many systems.
>>
>> While 99.9% of the time a DO variable should not be real, it doesn't
>> seem so bad to have it in the language for the times it is useful.
>> It seems to be a deleted feature.
> 
> What does it do? Convert the real number to integer and throw away the 
> digits? Or does it round-off to index something?

The standard doesn't say!  However, real subscripts are always
truncated to integer.  A(x) is treated as if it were A(INT(x)).

Floating point DO loops are done in the natural way.  For
     DO X = 0.0, 1.0, .01
X will take on the values 0.0, .01, .02, .03, ...
These were standard, but have now been deleted from the language.

The problem is round off error in the successive adds to X.  On
different machines, the above loop could execute 99, 100, or 101
times.  Also, if you then use something like  A(100*X) = 0 you will
store twice into some variables and skip storing into some.

Dick Hendrickson

> 
>>> However, that doesn't directly relate to your problem with the output.
>> (snip)
>>  > You are printing that times 180/pi, which
>>> would be something more like 3139..... that is assuming that you intend
>>> pi to be approximately 3.14159 or so. However, you never defined pi, so
>>> it is presumably some random value from whatever was in memory. Just
>>> because you named it pi, that doesn't mean it automatically has the
>>> value you intend.
> 
> Yep, ok.
0
11/8/2007 6:11:20 PM
In article <cjIYi.6708$if6.3510@bgtnsc05-news.ops.worldnet.att.net>,
Dick Hendrickson  <dick.hendrickson@att.net> wrote:
>
>Floating point DO loops are done in the natural way.  For
>     DO X = 0.0, 1.0, .01
>X will take on the values 0.0, .01, .02, .03, ...
>These were standard, but have now been deleted from the language.
>
>The problem is round off error in the successive adds to X.  On
>different machines, the above loop could execute 99, 100, or 101
>times.  

How could 99 times happen?  
      DO I = 0, 100, 1 
would execute 101 times.

But there is another problem that Dick didn't mention. I used to write
      DO X = 0.0, 1.005, 0.01
in cases like Dick's to ensure the correct number of times round the 
loop, until I found a different bad consequence of round-off error -
a value of X that the loop "ought" to have forbidden. This program:
      I = 0 
      DO X = 0.0, 1.0, 2.0/3000.0
         IF (X .GT. 0.999) PRINT *,I,X
         I = I + 1
      END DO
      END
compiles and runs with g77. It prints
 1499  0.999345005
 1500  1.00001168
I suspect it calculates how many times to go round the loop before 
starting, and does not check each time whether X is still .LE. 1.0.

-- John Harper, School of Mathematics, Statistics and Computer Science, 
Victoria University, PO Box 600, Wellington 6140, New Zealand
e-mail john.harper@vuw.ac.nz phone (+64)(4)463 5341 fax (+64)(4)463 5045
0
harper (719)
11/8/2007 9:19:34 PM
John Harper wrote:
> In article <cjIYi.6708$if6.3510@bgtnsc05-news.ops.worldnet.att.net>,
> Dick Hendrickson  <dick.hendrickson@att.net> wrote:
>> Floating point DO loops are done in the natural way.  For
>>     DO X = 0.0, 1.0, .01
>> X will take on the values 0.0, .01, .02, .03, ...
>> These were standard, but have now been deleted from the language.
>>
>> The problem is round off error in the successive adds to X.  On
>> different machines, the above loop could execute 99, 100, or 101
>> times.  
> 
> How could 99 times happen?  
>       DO I = 0, 100, 1 
> would execute 101 times.

Two possibilities:
1) a machine where some silly twit didn't think through what
    he was thinking about carefully enough

2)  a machine where the "best internal approximation" to .01
     was approximately .0102

More seriously, given bad enough selection of loop values I
think you can get n-1, n, or n+1 iterations when the integer
equivalent would give n iterations.

Dick Hendrickson
> 
> But there is another problem that Dick didn't mention. I used to write
>       DO X = 0.0, 1.005, 0.01
> in cases like Dick's to ensure the correct number of times round the 
> loop, until I found a different bad consequence of round-off error -
> a value of X that the loop "ought" to have forbidden. This program:
>       I = 0 
>       DO X = 0.0, 1.0, 2.0/3000.0
>          IF (X .GT. 0.999) PRINT *,I,X
>          I = I + 1
>       END DO
>       END
> compiles and runs with g77. It prints
>  1499  0.999345005
>  1500  1.00001168
> I suspect it calculates how many times to go round the loop before 
> starting, and does not check each time whether X is still .LE. 1.0.
> 
> -- John Harper, School of Mathematics, Statistics and Computer Science, 
> Victoria University, PO Box 600, Wellington 6140, New Zealand
> e-mail john.harper@vuw.ac.nz phone (+64)(4)463 5341 fax (+64)(4)463 5045
0
11/9/2007 1:21:39 AM
Dick Hendrickson wrote:
> Martin J�rgensen wrote:
>> glen herrmannsfeldt wrote:
>>> Richard Maine wrote:
>>>
>>> (snip)
>>>
>>>>>   do e=1,n
>>>>>      print*,'e=',e,': ', (element(e)%element_angle)*180/pi
>>>>>      element(e)%element_angle = 999.0
>>>>>   end do
>>>
>>> (snip)
>>>
>>>>> Warning: Extension: REAL array index at (1)
>>>
>>>> First note that this is not a compilation error. It is a warning rather
>>>> than an error. If it were an error, the compiler would not have made a
>>>> runnable executable. However, the problem should still be fixed.
>>>
>>>> The problem is that e is implicitly of real type because you never gave
>>>> it a type. I strongly recommend explicitly typing everything and using
>>>> implicit none to enforce that. You should declare e as integer. As the
>>>> message implies, it is nonstandard to use a real varoable as an array
>>>> index, but the compiler accepts it anyway. It is also obsolescent (or
>>>> maybe a deleted feature; I'd have to check to be sure) to use a real
>>>> variable as a loop index.
>>>
>>> REAL variables as subscripts are an extension in many systems.
>>>
>>> While 99.9% of the time a DO variable should not be real, it doesn't
>>> seem so bad to have it in the language for the times it is useful.
>>> It seems to be a deleted feature.
>>
>> What does it do? Convert the real number to integer and throw away the 
>> digits? Or does it round-off to index something?
> 
> The standard doesn't say!  However, real subscripts are always

Ok, enough for me to know not to use it...

> truncated to integer.  A(x) is treated as if it were A(INT(x)).

Ok.

> Floating point DO loops are done in the natural way.  For
>     DO X = 0.0, 1.0, .01
> X will take on the values 0.0, .01, .02, .03, ...
> These were standard, but have now been deleted from the language.

Not standard, so I should use it?

> The problem is round off error in the successive adds to X.  On
> different machines, the above loop could execute 99, 100, or 101
> times.  Also, if you then use something like  A(100*X) = 0 you will
> store twice into some variables and skip storing into some.

Ok, I understand.


Regards,
Martin
0
megafedt (49)
11/9/2007 6:16:00 PM
Hello,

Martin J�rgensen wrote:
> Dick Hendrickson wrote:

>> Floating point DO loops are done in the natural way.  For
>>     DO X = 0.0, 1.0, .01
>> X will take on the values 0.0, .01, .02, .03, ...
>> These were standard, but have now been deleted from the language.
> 
> Not standard, so I should use it?

I've always believed the best substitute is something like

do i = 1, n

    real_value = first_real_value + real_increment * ( i - 1)

which avoids floating point addition to the extent possible.

-- 

Dan Nagle
Purple Sage Computing Solutions, Inc.
0
dannagle (1018)
11/9/2007 6:27:22 PM
Dick Hendrickson wrote:

(snip)

> The standard doesn't say!  However, real subscripts are always
> truncated to integer.  A(x) is treated as if it were A(INT(x)).

I believe that is what implementations that allow real
subscripts do.  I used to sometimes do translations of BASIC
programs, where all variables are REAL.

> Floating point DO loops are done in the natural way.  For
>     DO X = 0.0, 1.0, .01
> X will take on the values 0.0, .01, .02, .03, ...
> These were standard, but have now been deleted from the language.

> The problem is round off error in the successive adds to X.  On
> different machines, the above loop could execute 99, 100, or 101
> times.  Also, if you then use something like  A(100*X) = 0 you will
> store twice into some variables and skip storing into some.
(I think you might have meant 100, 101, 102, though.)

There are some problems where such roundoff doesn't matter.
(Interpolation and root finding might be some of them.)

I don't believe in removing language features that might be
used in the wrong way.  It is up to the user to know how to
use language features.  Note that many other languages do allow
REAL variables in their indexed loop construct.

-- glen

0
gah (12851)
11/9/2007 8:59:21 PM
Reply: