Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

d1mach subroutine (Slatec)

Status
Not open for further replies.

dende1980

Programmer
Nov 10, 2010
2
CH
Hello everybody

I'm using the Slatec library and I found that I had to deal with the subroutines d1mach and i1mach that take into account the processor I'm working with to set the machine precission that my computer can support.

Besides the fact that I couldn't find the kind of processor that I'm using (Intel Q6600), and that in the end I chose the option the most similar to my processor, I received some compiling error regarding the overflow of a variable that was declared as integer but declared as equivalent as a double precision.

I have to admit that I had never used the "Equivalence" command, so I didn't understand exactly what was going on. But my surprise was big when I saw that the compiler error only occurred for the variable whose value was the biggest, not for the smallest one. I have to say that the variables were declared as integer but assigned double precision values, so I thought that this was the problem in the beginning, but I found out that the "Equivalence" command prevents this problem to occur (if dealt correctly).

Please, find below the part of the code that concerns the problem (I've skipped a lot of lines containing only data):


<<
*DECK D1MACH
DOUBLE PRECISION FUNCTION D1MACH (I)
INTEGER SMALL(4)
INTEGER LARGE(4)
INTEGER RIGHT(4)
INTEGER DIVER(4)
INTEGER LOG10(4)

DOUBLE PRECISION DMACH(5)
SAVE DMACH

EQUIVALENCE (DMACH(1),SMALL(1))
EQUIVALENCE (DMACH(2),LARGE(1))
EQUIVALENCE (DMACH(3),RIGHT(1))
EQUIVALENCE (DMACH(4),DIVER(1))
EQUIVALENCE (DMACH(5),LOG10(1))

C..............................................

C MACHINE CONSTANTS FOR THE IBM PC
C ASSUMES THAT ALL ARITHMETIC IS DONE IN DOUBLE
C PRECISION ON 8088, I.E., NOT IN 80 BIT FORM FOR THE C 8087.
C
C DATA SMALL(1) / 2.23D-308 /
C DATA LARGE(1) / 1.79D+308 /
C DATA RIGHT(1) / 1.11D-16 /
C DATA DIVER(1) / 2.22D-16 /
C DATA LOG10(1) / 0.301029995663981195D0 /
>>

The compiler error is the following:

"Error: The value of the integer is either too great or too small, and overflow/underflow occurred. [1.79D+308]
DATA LARGE(1) / 1.79D+308 /"

Could anybody help me to understand why do I receive a compile error for the overflow of the variable LARGE and not an underflow error message for the variable SMALL?

I have to say that when I decreased the value of LARGE in the data statement line to 1e+17 the compiler didn't complain anymore.

Thank you very much for your help.
 

This programming is not standard conforming. One cannot set a double precision value within an integer value.

It is easy to correct it in declaring DOUBLE PRECISION the variables SMALL LARGE RIGHT DIVER and LOG10

In addition, I don't understand why the array DMACH is not simply initialized with a DATA statement :

Code:
DATA DMACH/2.23D-308,1.79D+308,1.11D-16,2.22D-16,0.301029995663981195D0/

In that case, of course, the other variables SMALL, LARGE ... are useless... except if they are used in the rest of the code.

If one initializes DMACH rather than the other variables, then these variables can be declared INTEGER (but this is really strange) and become automatically initialized thanks to the EQUIVALENCE statements.

At last, I suggest the use of FORTRAN-90 intrinsic functions instead of constant values in DATA :

TINY(1.d0) <=> 2.23D-308
HUGE(1.d0) <=> 1.79D+308
EPSILON(1.d0)/2 <=> 1.11D-16
EPSILON(1.d0) <=> 2.22D-16
LOG10(2.d0) <=> 0.301029995663981195D0





François Jacq
 
I fully agree with you about how weird is the use of a declaration of an integer whose assigned value is double precission one. I understand that the use of the EQUIVALENCE command avoid compiler errors. But it's true, as you suggested, that some of these integers are called from other subroutines.

In any case I don't understand why I receive a compiler error in one of the variables and not in the remainder.

But thanks for your fast answer anyway.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top