How to Determine Highest Precision Available on a PC ??
in [Fortran]
|
Prev: Programmer's Paradise
Next: Reading a .wav file
From: James Van Buskirk on 9 Aug 2010 19:02 "steve" <kargls(a)comcast.net> wrote in message news:9ea8cbd0-b40f-4dbc-8d7e-8a6465abbbe9(a)h40g2000pro.googlegroups.com... > On Aug 9, 2:26 pm, "James Van Buskirk" <not_va...(a)comcast.net> wrote: > > gfortran does support 10-byte extended > > precision on x86-64, but the support as it comes with the compiler is > > only partial and you have to perform a further song and dance to get > > even that partial support to work. > Can you elaborate on what your song and dance are? > gfortran has supported REAL(10) for a very long time. > There, of course, could be a few bugs lurking, but unreported > bugs have little chance in being fixed. Well, there used to be a problem on 64-bit Windows that MicroSoft would set the precision bits of the x87 control word for 53-bit precision whereas REAL(10) requires them to be set for 64-bit precision. Thus a program such as: C:\gfortran\clf\realstar10>type realstar10.f90 module mod implicit none integer, parameter :: ep = selected_real_kind(precision(1.0d0)+1) end module mod program realstar10 use mod implicit none interface subroutine xfinit() bind(C,name='_xfinit_') end subroutine xfinit subroutine sub(x) use mod implicit none real(ep) x end subroutine sub end interface real(ep) x write(*,'(3(a,i0))') 'ep = ', ep, ', precision = ', & precision(1.0_ep), ', range = ', range(1.0_ep) x = 1.0_ep call sub(x) call xfinit call sub(x) end program realstar10 subroutine sub(x) use mod implicit none real(ep) pi, x, y pi = 4*atan(1.0_ep) write(*,*) pi y = pi/7 write(*,*) y end subroutine sub C:\gfortran\clf\realstar10>type finit.s .text ..globl _xfinit_ .def _xfinit_; .scl 2; .type 32; .endef _xfinit_: finit ret C:\gfortran\clf\realstar10>as finit.s -ofinit.o C:\gfortran\clf\realstar10>gfortran -fno-whole-file realstar10.f90 finit.o -orea lstar10 C:\gfortran\clf\realstar10>realstar10 ep = 10, precision = 18, range = 4931 3.1415926535897932385 0.44879895051282760552 3.1415926535897932385 0.44879895051282760552 could demonstrate that gfortran didn't set up the x87 control word correctly. This doesn't seem to have that effect today so perhaps this situation has been ameliorated. There also used to be issues about some REAL(10) intrinsics being implemented in initialization expressions but not in ordinary expressions, although some correspondence in the gfortran mailing list indicates that FX has perhaps done something in that area as well. I've been too tired to check for fixes lately so maybe I'm just too far outside the loop at this point. -- write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, & 6.0134700243160014d-154/),(/'x'/)); end
From: mecej4 on 9 Aug 2010 20:15 monir wrote: > Hello; > > Suppose one needs to use a higher precision than "double-precision" > reals. <--CUT--> > 3) Is it possible to use an F90 intrinsic function (if available) to > automatically assign reals to the highest precision (for > portability) ?? > (something similar to using TINY() or EPSILON() in a numerical model) > Even if this could be done easily, I think that requesting the highest precision possible _automatically_ would be an unwise thing to do. On hardware capable of no more than 53-bit native precision, it may possible for a compiler to emulate, say, 105-bit precision, taking over four times the machine cycles needed for 53-bit precision. If your calculation uses inputs that are not sufficiently precise, or uses an algorithm that has high discretization errors, that calculation is incapable of benefitting from the extended precision. You would have made the program > 4 times slower, but with no gain to show for it. -- mecej4
From: glen herrmannsfeldt on 9 Aug 2010 21:16 mecej4 <mecej4.nyetspam(a)opferamail.com> wrote: (snip) > Even if this could be done easily, I think that requesting the highest > precision possible _automatically_ would be an unwise thing to do. > On hardware capable of no more than 53-bit native precision, it may possible > for a compiler to emulate, say, 105-bit precision, taking over four times > the machine cycles needed for 53-bit precision. Likely much more than four times. Maybe four for add, and much more for multiply and divide. > If your calculation uses inputs that are not sufficiently precise, or uses > an algorithm that has high discretization errors, that calculation is > incapable of benefitting from the extended precision. You would have made > the program > 4 times slower, but with no gain to show for it. Well, there are some calculations where you really need the precision. In many case, it is better to find another algorithm, though. Of course if you want to calculate 100 digits of pi, you really need to calculate to (a little over) 100 digits. -- glen
From: monir on 10 Aug 2010 12:50 Hello; Thank you all for your thoughtful replies. 1) I must admit that I intentionally omitted the mention of h/w or s/w in my OP. The reason is rather simple ... I wasn't sure! My dilemma was that on one hand the compiler must support the requested (high) precision, and on the other, the requested precision must be available in the hardware. The question then becomes how to (automatically) determine the highest precision available on a particular computer (processor, h/w) and use such info to (automatically) declare real variables in F90 code (s/w), and in the process avoid possible conflict with the compiler (s/w). In order not to restrict responses, I decided not to mention h/w or s/ w in the OP and see what the experts would say or suggest. 2) Some of you have raised some concerns and possible conflict between requesting higher precision, portability, numerical results, slow-down, etc. My objective is to be sure that I'm using the highest precision available on a particular m/c regardless of the end results. As some of you have already stated, some sensitive calculations need precision higher than DP. Developing another procedure is not an option at this time. As a matter of fact, some other academia are currently trying 80 decimal digits precision on a similar problem (with completely different boundary conditions; so it is not really similar!). Anyway, I reckon, supported by some numerical evidence, that quadruple- precision declaration (if available) would be adequate for the application. 3) I've tried Steve's and Buskirk's examples to better understand the two intrinsic functions: .... Selected_Real_Kind() and Precision() and whether either or both could be used (correctly) in this exercise. .... m/c: Toshiba: Intel Pentium 4 CPU 3.06GHz x86 processor ... ..a. (Steve-Avail-Precision-3.F90) requested decimal digits returned kind by "i" Selected_Real_Kind(i) 1 . . . . . . . . . . . 4 6 . . . . . . . . . . . 4 7 . . . . . . . . . . . .8 15 . . . . . . . . . . . .8 16 . . . . . . . . . . . . 10 18 . . . . . . . . . . . . 10 19 . . . . . . . . . . . . . 16 --> 33 . . . . . . . . . . . . . 16 <-- 34 . . . . . . . . . . . . . . -1 35 . . . . . . . . . . . . . . -1 Based on the above, the requested i>=34 precision is not available on this computer. Correct ?? Also, the intrinsic Selected_... returns the same kind of the type real (16) for the desired 19 to 33 decimal digits. Does this make sense ?? 4) On the other hand, trying James Van Buskirk's example (his 1st reply) with different compilers gives: ..b. (Buskirk-Avail-Precision-1.F90) i. w gfortran compiler: sp = 4, precision(sp) = 6 dp = 8, precision(dp) = 15 ep = 10, precision(ep) = 18 qp = 10, precision(qp) = 18 ii. w g95 compiler: sp = 4, precision(sp) = 6 dp = 8, precision(dp) = 15 ep = 10, precision(ep) = 18 --> qp = 16, precision(qp) = 33 <-- iii.w ifort compiler (James' results): sp = 4, precision(sp) = 6 dp = 8, precision(dp) = 15 ep = 16, precision(ep) = 33 qp = 16, precision(qp) = 33 Notice how the different compilers (on the same computer) respond differently at higher precision ep & qp! 5) Based on the results 3.a. and 4.ii. above one may reasonably conclude that on this particular computer the maximum precision is 33 decimal digits. Correct ?? Kind regards. Monir
From: steve on 10 Aug 2010 13:09
On Aug 10, 9:50 am, monir <mon...(a)rogers.com> wrote: > > .a. (Steve-Avail-Precision-3.F90) > requested decimal digits returned kind by > "i" Selected_Real_Kind(i) > 1 . . . . . . . . . . . 4 > 6 . . . . . . . . . . . 4 > 7 . . . . . . . . . . . .8 > 15 . . . . . . . . . . . .8 > 16 . . . . . . . . . . . . 10 > 18 . . . . . . . . . . . . 10 > 19 . . . . . . . . . . . . . 16 > --> 33 . . . . . . . . . . . . . 16 <-- > 34 . . . . . . . . . . . . . . -1 > 35 . . . . . . . . . . . . . . -1 > > Based on the above, the requested i>=34 precision is not available on > this computer. Correct ?? Correct to the extent that you aren't using a high precision math library. For example, David Bailey's libs at http://crd.lbl.gov/~dhbailey/mpdist/ > 4) On the other hand, trying James Van Buskirk's example (his 1st > reply) with different compilers gives: > > .b. (Buskirk-Avail-Precision-1.F90) > > i. w gfortran compiler: > sp = 4, precision(sp) = 6 > dp = 8, precision(dp) = 15 > ep = 10, precision(ep) = 18 > qp = 10, precision(qp) = 18 This may change in the future. A software implementation of qp has been floated (pun intended) on the fortran(a)gnu mailing list. > ii. w g95 compiler: > sp = 4, precision(sp) = 6 > dp = 8, precision(dp) = 15 > ep = 10, precision(ep) = 18 > --> qp = 16, precision(qp) = 33 <-- > (snip) > 5) Based on the results 3.a. and 4.ii. above one may reasonably > conclude that on this > particular computer the maximum precision is 33 decimal digits. > Correct ?? Hardware or software? With Bailey's libs you can specify an arbitrary precision. -- steve |