forums.silverfrost.com

[KL]

Dear Paul,

The program Denormalised_Operand.f95 leads to the error message (FTN95 Verion 4.7):

Denormalised operand
Floating point co-processor fault at address 0040148b

I have run the problem with the file run.bat:

del comp.lis
del *.obj
del *.exe

rem Ftn95 DataTypes.f95 /Checkmate >> comp.lis
rem Ftn95 Denormalised_Operand.f95 /Checkmate /underflow >> comp.lis
rem Ftn95 Coeff_linear.f95 /Checkmate /underflow >> comp.lis
rem Ftn95 GaussTransformation.f95 /Checkmate /underflow >> comp.lis

rem slink $linklist

rem sdbg Denormalised_Operand.exe


Ftn95 DataTypes.f95 >> comp.lis
Ftn95 Denormalised_Operand.f95 /underflow >> comp.lis
Ftn95 Coeff_linear.f95 /underflow >> comp.lis
Ftn95 GaussTransformation.f95 /underflow >> comp.lis

slink $linklist

Denormalised_Operand.exe



Comment: When using the option /CHECKMATE this error does not occur (see first part of “run.bat”).

In my opinion, there is no error in the program. In subroutine Coeff_linear only the upper triangle of a matrix A is defined and returned to the calling subroutine GaussTransformation.f95. Thus, the whole matrix A is undefined, but it is nowhere used as a whole matrix. This programming technique is frequently used in solving a linear system of equations with a symmetric matrix.

Here are the programs:

Winapp
Program Denormalised_Operand

! ------------------------------------------------------------------

Use DataTypes

Implicit none

! ------------------------------------------------------------------

Interface
Subroutine GaussTransformation ( Fail )
Use DataTypes
Implicit none
Logical (lgt), Intent (out) :: Fail
End Subroutine GaussTransformation
End Interface

! ------------------------------------------------------------------

Logical (lgt) :: Fail

! ------------------------------------------------------------------


Call GaussTransformation ( Fail )
! ########################


End Program Denormalised_Operand



Subroutine GaussTransformation ( Fail )
! ##############################


! ------------------------------------------------------------------

Use DataTypes

Implicit none

Logical (lgt), Intent (out) :: Fail

! ------------------------------------------------------------------

Integer (I4B), Parameter :: w_dim = 25

Real (dp) , Dimension (w_dim,w_dim) :: A

Integer (I4B) :: n_Intervals

! ------------------------------------------------------------------

Interface
Subroutine Coeff_linear ( A )
Use DataTypes
Implicit none
Real (dp) , Dimension (:,, Intent (out) :: A
End Subroutine Coeff_linear
End Interface

! ------------------------------------------------------------------

! n_Intervals = 3 works correctly !!!!

n_Intervals = 4

! ------------------------------------------------------------------


Call Coeff_linear ( A (1:n_Intervals,1:n_Intervals) )
! #################

fail = .false.

! ------------------------------------------------------------------


write (*,*) 'Subroutine GaussTransformation'
write (*,*) '=============================='
write (*,*)
write (*,*) 'Correct Stop'
write (*,*) '############'


stop


! ------------------------------------------------------------------

End Subroutine GaussTransformation



Subroutine Coeff_linear ( A )
! #######################

!

[PaulLaidler]

Klaus

Thanks for your email.

I cannot get this one to fail. I have not had time to check back to version 4.7 but I am reasonably confident that the bug will have been fixed by version 4.91 (the latest release). However, if you want to wait a few days you will be able to upgrade to version 5.0 which is the version I am testing against.

We will aim to investage the other samples which appear to indicate outstanding bugs.

Regards

Paul

[JohnCampbell]

Klaus,

Should "Use DataTypes" and "Implicit none" be used in any interface statement, when they are already defined ?
Does subroutine GaussTransformation require an interface ?

I tested the code, as a single file and everything worked ok.

Also, why use kind sp as it has only 6 digit accuracy? You should use your
dp : selected_real_kind(15,0), real*8 or
selected_real_kind(18,0), real*10

The following code tests possible kind values for Salford. A problem with KIND is there are only a few realistic values of available precision. It's not as if we can just prescribe a precision and the compiler generates a variable type !

! Test possible values of kind selection
!
integer*4, parameter :: r6 = selected_real_kind(6,0)
integer*4, parameter :: r15 = selected_real_kind(15,0)
integer*4, parameter :: r18 = selected_real_kind(18,0)
!
real(r6) :: x6 = 0
real(r15) :: x15 = 0
real(r18) :: x18 = 0
!
integer*4, parameter :: i2 = selected_int_kind(2)
integer*4, parameter :: i4 = selected_int_kind(4)
integer*4, parameter :: i9 = selected_int_kind(9)
integer*4, parameter :: i18 = selected_int_kind(1
!
integer(i2) :: j2 = 0
integer(i4) :: j4 = 0
integer(i9) :: j9 = 0
integer(i18) :: j18 = 0
!
write (*,*) 'r6 ', r6, precision(x6), int(log10(huge(x6)))
write (*,*) 'r15', r15, precision(x15), int(log10(huge(x15)))
write (*,*) 'r18', r18, precision(x18), int(log10(huge(x18)))
!
write (*,*) 'i2 ', i2, range(j2), int(log10(dble(huge(j2))) )
write (*,*) 'i4 ', i4, range(j4), int(log10(dble(huge(j4))) )
write (*,*) 'i9 ', i9, range(j9), int(log10(dble(huge(j9))) )
write (*,*) 'i18', i18, range(j18), int(log10(dble(huge(j18))))
!
end

[KL]

Dear Mr. Campbell,

thank you for your remarks.

The following remarks are valid for a "normal" programme.

In the present case the interface is not necessary. However, both statements
are "normally" necessary:

1. An interface body does not
access its environment by host association, and therefore
it cannot use named constant unless they are defined.
There is a trick (import statement) to circumvent
this. However, the "Use DataTypes" is simple and clear.

2. The statement "Implicit none" enforces that all variables
in the interface block are defined explicitly. The same
statement in the main programme is not valid for the interface block.

The error occurred with FTN95 version 4.7 but only under the condition mentioned.

I am familiar with the concept of kind and accuracy.
Concerning accuracy, I guess that 95 percent of all
scientific problems can be solved with single precision.
So there is nothing wrong using SP as kind type parameter.
By the way, I took it from Numerical Recipes.

Best regards,

Klaus Lassmann

K. Lassmann

[JohnCampbell]

Klaus,

You've got me wondering about this one ! I modified your code to :

Subroutine GaussTransformation ( Fail )
! ##############################

Use DataTypes
Implicit none

Logical (lgt), Intent (out) :: Fail
Integer (I4B), Parameter :: w_dim = 25
Real (dp) , Dimension (w_dim,w_dim) :: A
Integer (I4B) :: n_Intervals

Interface
Subroutine Coeff_linear ( A )
! Use DataTypes
! Implicit none
Real (dp) , Dimension (:,, Intent (out) :: A
End Subroutine Coeff_linear
End Interface

n_Intervals = 4
...

and this compiled sucessfully. Should the parameter definition of dp not been available to the intrerface ? To me the use of implicit none seems strange in an interface definition.

As for the use of SP in 95% of scientific calculation, scientific is a very broard field and must not include the area in which I work. My observation is that the use of dp is an easy and safer alternative to adopt. Real*10 should be better, but the changes by microsoft to limit math accuracy to 64bit confuse that a little. Good luck with your sp.

[KL]

I have rerun this problem with FTN95 v5.0 and the error is still there when compiled without /Checkmate. I give the bat file again:

del comp.lis
del *.obj
del *.exe

Ftn95 DataTypes.f95 >> comp.lis
Ftn95 Denormalised_Operand.f95 /underflow >> comp.lis
Ftn95 Coeff_linear.f95 /underflow >> comp.lis
Ftn95 GaussTransformation.f95 /underflow >> comp.lis

slink $linklist

Denormalised_Operand.exe

The link file “linklist” is:
LOAD Denormalised_Operand
LOAD DataTypes
LOAD Coeff_linear
LOAD GaussTransformation
file Denormalised_Operand

Best regards

Klaus Lassmann

[PaulLaidler]

Klaus

I have had another look at this.

I still cannot get it to fail.

Maybe it is something to do with the subroutine coeff_linear that is not defined in your message.

[KL]

Sorry Paul,

here is the missing subroutine

Subroutine Coeff_linear ( A )
! #######################

! ------------------------------------------------------------------

Use DataTypes

Implicit none

Real (dp), Dimension (:,, Intent (out) :: A

! ------------------------------------------------------------------

Integer (I4B) :: i, j, n_intervals

! ------------------------------------------------------------------

write (*,*) 'Coeff_linear'
write (*,*) '============'
write (*,*)
write (*,*) 'size a =', size (a,1)
write (*,*) 'size a =', size (a,2)
write (*,*)

n_Intervals = size ( a,1 )

! ------------------------------------------------------------------

! A = 0._dp ! works correctly

do i = 1, n_Intervals
do j = i, n_Intervals
A (i,j) = 0.d+00
End Do
End Do

! ------------------------------------------------------------------

do i = 1, n_Intervals
write (*,*) 'i = ', i
do j = i, n_Intervals
write (*,*) 'a = ', A (i,j)
End Do
End Do

write (*,*) 'End Coeff_linear'
write (*,*) '================'
write (*,*)

End Subroutine Coeff_linear