Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Announcements
FPGA community forums and blogs on community.intel.com are migrating to the new Altera Community and are read-only. For urgent support needs during this transition, please visit the FPGA Design Resources page or contact an Altera Authorized Distributor.
29280 Discussions

Default Real KIND and effects on intrinsic functions

mr_katse
Beginner
626 Views
hi!

instead of changing all single-precision real data types in my code i changed the "default real kind"-option (properties -> fortran -> data) to "8 (/real_size:64)" from "4" ( the definitions are "real" and not "real*4").

in the code i use some intrinsic functions, like MIN or ABS. do i have to change all these functions to DMIN1 or DABS?

if i change the "default real kind" to "16 (/real_size:128)" visual studio crashes when i start debugging. is this normal?

EDIT:

i am using ridders' method from numerical recipies for fortran for a root finding problem. the results improved very much when i moved from real*4 to real*8. unfortunately there is no big difference between the real*8 and real*16 results. can i expect this? the problem is, that i am not finding the true root value due to numerical issues.

thank you!

0 Kudos
4 Replies
Arjen_Markus
Honored Contributor II
626 Views

The names MIN and ABs are generic names - the compiler makes sure the right functions or inline code is chosen. (This has been the case since at least FORTRAN 77).

Another way of doing what you do is to use the KIND mechanism. That is a portable way of controlling the precision and independent ofcompile options.

Regards,

Arjen

0 Kudos
mr_katse
Beginner
626 Views
thanks. i was thinking about something like that, but wanted to be sure.

i edited my first post with this question/issue:

i am using ridders' method from numerical recipies for fortran for a root finding problem. the results improved very much when i moved from real*4 to real*8. unfortunately there is no big difference between the real*8 and real*16 results. can i expect this? the problem is, that i am not finding the true root value due to numerical issues.
0 Kudos
Arjen_Markus
Honored Contributor II
626 Views
I do not know what function you are to find the root(s) for, so it is difficult or rather impossible, for me
to make much comments. But what do you mean by finding the true root value? You mean that you
know analytically what the root should be and you are getting an approximation that iscorrect in, say, 6 or
even 10 decimals? Or is the root completely off mark?

Can you be more specific?

My general feeling is that double precision is quite enough for almost all applications and even single
precision will do fine in the majority. Quadruple precision would be overkill. But it really does depend
on the application.

Therefore: can you show us an example where you feel the root is not accurate enough or at all
approximated?

Regards,

Arjen

0 Kudos
mr_katse
Beginner
626 Views
i have a set of equations which are calculated one after each other. the equations describe a reservoir cascade and the output Oi(t) of the top reservoir is used as an input to the next reservoir and so on. the whole system has an overall input I1(t) and and overall output O1(t) and is non-linear.

now, what i am trying to do is to estimate an input I2(t) (which has an output O2(t)), which is identical to I1(t) by solving O1(t)-O2(t) = 0. so the idea is that i only know O1(t) and not I1(t). i always (!) find a I2(t) to fulfill O1(t)-O2(t) = 0, but I1(t) and I2(t) must not be identical. with real*4 I1(t) and I2(t) were quite often different. as soon as i changed to real*8 the results were much better. in a first loop i calculate O1(t) and in a second loop i calculate O2(t) which i compare to O1(t). the same code is used. so it seems to be a problem of computing precision.

i have set floating point model to "/fp:precise", extend precision... to "/fp:constant" and floating-point speculation to "strict".

is this ok? what else can i do to guarantee a precise calculation.


0 Kudos
Reply