Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

about accuracy of the estimations

keremusu1
Beginner
906 Views

Hello!

1. How can I increase the number of decimals of the calculated variablesto increase the accuracy of the final estimation which depends on these variables.

2.How can I introduce the number E22 (10**22) to the fortran source code. I tried to write as n=E22 but ithas taken it as 0.Should I increase the number of digits that is taken into account or what?

Thanks.

0 Kudos
5 Replies
TimP
Honored Contributor III
906 Views
1. It's not clear whether you mean increasing precision from default, e.g.
real(selected_real_kind(12)) :: a
2. It looks like you meant something like
real :: n=1e22
The 1 isn't optional, and you will run into trouble if you don't declare data types.
If your textbook or online tutorial doesn't explain these questions, several better ones are available.

0 Kudos
keremusu1
Beginner
906 Views
Where can I find these online tutorials. Can you please give me the URLs.
0 Kudos
jimdempseyatthecove
Honored Contributor III
906 Views

Keremusu,

Floating point literals (constants) are generally converted from the source file into binary code using the default floating point precision. This is generally REAL(4). You can override this behavior (as shown by the example on your other thread) by various means.

10E22generally a REAL(4)
10E22_8explicitly REAL(8)

Look at the documentation under double precision constants.

Jim Dempsey

0 Kudos
Steven_L_Intel1
Employee
906 Views
True, but even REAL(8) isn't going to help with a number as large as 10E22 - not enough bits in the binary fraction.
0 Kudos
jimdempseyatthecove
Honored Contributor III
906 Views

Steve,

>> True, but even REAL(8) isn't going to help with a number as large as 10E22 - not enough bits in the binary fraction.

Yes. I may take more than 53 bits to express that number.

However, that said. If his original huge data array has meaningful data, each expressible within 53 bits of mantissa, but where the full range of bits required could be over 100 bits of mantissa, reasonably better summation estimates can be attained by adding numbers within the array that have similar magnitudes. In this manner the LSBs of the small value numbers are not shifted out when added to a large value number (at least until the last step in the summation). The code I listed might be inadequite but certainly could be expanded upon. The final result would still be 53 bits but the summation loop could easily be expanded to produce a better number

Jim

0 Kudos
Reply